| |
|
| |
| | 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. |
| | Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks |
| |
|
Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. |
| | Segment Routing Path MTU in BGP |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE) |
| |
| | draft-ietf-jose-hpke-encrypt-15.txt |
| | Date: |
30/11/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This specification defines how to use Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE). HPKE enables public key encryption of arbitrary-sized plaintexts to a recipient's public key, and provides security against adaptive chosen ciphertext attacks. This specification chooses a specific subset of the HPKE features to use with JWE. This specification updates RFC 7516 (JWE) to enable use of the Integrated Encryption Key Establishment Mode. |
| | 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. |
| | Adding a Wrong Recipient URL for Handling Misdirected Emails |
| |
|
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. About This Document This note is to be removed before publishing as an RFC. Discussion of this document takes place on the MAILMAINT Working Group mailing list (mailto:mailmaint@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mailmaint/. Subscribe at https://www.ietf.org/mailman/listinfo/mailmaint/. Source for this draft and an issue tracker can be found at https://github.com/dweekly/ietf-wrong-recipient. |
| | Registration of further IMAP/JMAP keywords and mailbox name attributes |
| |
|
This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It defines the intended use of these keywords and mailbox name attributes. This document registers all of these with IANA to avoid name collisions. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | 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. |
| | 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. |
| | IP Payload Compression excluding transport layer |
| |
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. |
| | Segment Routing Policy-Based Source Address Validation (SAV) Mechanism |
| |
|
This draft proposes a novel mechanism for Source Address Validation (SAV) message propagation based on Segment Routing policies (SR- policy). Traditional SAV mechanisms often rely on routing tables (RIB) and Policy-Based Routing (PBR), but these methods lack the flexibility and granularity needed for some network environments. By leveraging the flexibility and control capabilities of SR-policy, the proposed mechanism ensures that SAV messages are propagated along well-defined paths, ensuring efficient, secure, and accurate source address validation. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform-agnostic profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. For enhanced strictness, as well as for enabling cryptographic methods like signing and hashing, to optionally be applied to "raw" (non-wrapped) CBOR data, deterministic encoding is mandated. Furthermore, the document outlines API features for manipulating CBOR data in a secure manner. This document mainly targets CBOR tool developers. |
| | DNS Security Extensions (DNSSEC) |
| |
|
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document obsoletes RFC 9364. This document is being tracked at (https://github.com/paulehoffman/ rfc9364bis). |
| | BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects |
| |
|
The Route Path Authorizations (RPA) is an RPKI object that attests to the 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. |
| | IETF In Memoriam 2025 |
| |
|
The primary purpose of this memo is to remember substantial contributors to the Internet Engineering Task Force who have passed away in the year 2025. Some substantial contributors who died in prior years are also recognized. This memo is NOT a general memorial notice for the broader Internet community. Rather it is centered on persons who made notable contributions to IETF. This memo is NOT the product of any IETF or IRTF working group. It is published in the Independent RFC Stream consistent with guidelines in RFC4846. |
| | GLobal Unique Enterprise (GLUE) Identifiers |
| |
| | draft-ietf-spice-glue-id-03.txt |
| | Date: |
30/11/2025 |
| | Authors: |
Brent Zundel, Pamela Dingle, Michael Jones |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification establishes a URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. This enables URN identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URN namespace. |
| | 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. |
| | Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6) |
| |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment Identifier (PSID) has been defined to identify an SR path in SR-MPLS networks, and is used for various use- cases such as end-to-end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the PSID to identify an SRv6 path in an IPv6 network. |
| |
|
| |
| | BGP Extensions for the Mobile User Plane (MUP) SAFI |
| |
| | draft-ietf-bess-mup-safi-00.txt |
| | Date: |
25/11/2025 |
| | Authors: |
Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. |
| | 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 used as an overlay network for such interconnects. The use of UMR has implications for EVPN MAC mobility procedures, for EVPN L2 and IRB operations, and for EVPN Proxy ARP/ND operations. This document describes additional enhancements required to EVPN procedures and operations when using UMR. This document updates RFC9014 to clarify and extend the proceduresfor UMR usage. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | Enhanced AS-Loop Detection for BGP |
| |
|
Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. |
| | MSYNC |
| |
| | draft-bichot-msync-19.txt |
| | Date: |
25/11/2025 |
| | Authors: |
Sophie Bale, Remy Brebion, Guillaume Bichot |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. |
| | Compressed SID (CSID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. |
| | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 9231. |
| | Applicability of Computing-Aware Traffic Steering to Intelligent Transportation Systems |
| |
|
This document describes the applicability of Computing-Aware Traffic Steering (CATS) to Intelligent Transportation Systems (ITS). CATS provides the steering of packets of a traffic flow for a specific service request toward the corresponding service instance at an edge computing server at a service site. CATS are applicable for Computing-Aware ITS including (i) Context-Aware Navigation Protocol (CNP) for Terrestrial Vehicles and Unmanned Aerial Vehicles (UAV), (ii) Edge-Assisted Cluster-Based MAC Protocol (ECMAC) for Software- Defined Vehicles, and (iii) Self-Adaptive Interactive Navigation Tool (SAINT) for Cloud-Based Navigation Services, and (iv) Cloud-Based Drone Navigation (CBDN) for Efficient Drone Battery Charging. |
| | Distributed Micro Service Communication architecture based on Content Semantic |
| |
|
This draft introduces a novel communication architecture, called Distributed Micro Service Communication architecture (DMSC). It includes multiple aspects of microservice communication, such as service registration, service discovery, service routing, service scheduling, and more , Which to achieve all the essential functionalities provided by current centralized service networks. By incorporating content-semantic communication, DMSC significantly enhances the performance, scalability, and reliability of microservice communication. It provides a robust architecture for managing the complex communication requirements of distributed microservices, ensuring data integrity, security, and efficient resource utilization. Furthermore, DMSC provides a reference direction for the transition of the service mesh infrastructure from a location-based model to a content- and service-centric paradigm. |
| | Intra-Domain On-Demand Source Address Validation(SAV) Mechanism |
| |
|
Source Address Validation (SAV) mechanisms, such as uRPF, ACLs, and BM-SPF, are applied to prevent IP source address spoofing. However, these mechanisms are typically designed for static routing scenarios and deployed at fixed network boundaries. With the increasing adoption of dynamic forwarding technologies such as SRv6 Policy and Fast Reroute (TI-FRR), the network's actual forwarding path may change frequently due to policy-based traffic steering or link failures. In such cases, statically deployed SAV rules may fail to validate traffic on newly activated or alternate paths, creating validation blind spots or even leading to false positives that block legitimate traffic. This draft proposes an On-Demand Source Address Validation Activation mechanism. It enables routers to dynamically activate or update SAV rules on specific interfaces only when the interface becomes part of an active forwarding path due to policy or failover triggers. This approach enhances SAV coverage, avoids unnecessary resource consumption, and ensures SAV correctness under dynamic path switching scenarios driven by SRv6-policy and TI-FRR. |
| | RPKI Repository Delta Protocol (RRDP) Delta File Retention Policy |
| |
|
This document updates RFC 8182 (The RPKI Repository Delta Protocol) by specifying an optimized delta file retention policy based on client access patterns. The proposed mechanism allows RRDP servers to maintain only the delta files required by active clients, reducing storage requirements while maintaining compatibility with existing clients. By tracking which serial numbers are being requested by active clients, the repository can determine the minimum serial number needed by any client and safely prune delta files that update from earlier serial numbers. The proposed mechanism provides several benefits, including reduced storage requirements, smaller notification files, and more efficient use of bandwidth and processing resources. It also maintains backward compatibility with existing RRDP clients, requiring no changes to client implementations. |
| | Agent Operation Authorization |
| |
|
This document specifies the Agent Operation Authorization framework — a structured mechanism that enables verifiable delegation of actions from human principals to autonomous AI agents with fine-grained agent operation authorization. The framework introduces two distinct phases: * *Agent Operation Authorization Request:* A human-readable proposal of operations derived from natural language input and converted to a JSON Web Token (JWT). * *Agent Operation Authorization Token:* A JSON Web Token representing confirmed authorization for a specific agent operation, enforceable at runtime by agents and verifiers. It cryptographically verifies user intent, prevents unauthorized or hallucinated actions, and ensures auditable traceability of each authorized operation. |
| | The DNS XFR URI Schemes |
| |
|
The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred. |
| | Service Status Resource Format for Web Services |
| |
|
This specification defines a standard JSON format for service status resources. It provides a machine-readable format for overall service health indicators, component-level status information with criticality classification, geographic scope identification, and structured incident reporting. This standard enables interoperability between status monitoring tools and service providers. |
| | NTP Over PTP |
| |
|
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers that can timestamp only PTP messages and enables delay corrections in PTP transparent clocks. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. |
| | SRv6 Policy SID List Optimization |
| |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes. In some use cases, an SRv6 Policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies procedures to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | 464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations |
| |
|
464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT. |
| |
|
| |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-19.txt |
| | Date: |
20/11/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 functional components, describes their interactions, and provides illustrative workflows of the control and data planes. |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-ietf-green-use-cases-00.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos |
| | Working Group: |
Getting Ready for Energy-Efficient Networking (green) |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases |
| | Extended Communities Derived from Route Targets |
| |
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. |
| | Advertising Flexible Algorithm Extensions in BGP Link-State |
| |
|
Flexible Algorithm is a solution that allows some routing protocols (IS-IS and OSPF) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by IS-IS and OSPF flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. |
| | IoT DNS Security and Privacy Guidelines |
| |
|
This document outlines best current practices for Internet of Things (IoT) device providers regarding the implementation of DNS stub resolvers, with the aim of mitigating security threats, enhancing privacy, and resolving operational challenges. It also provides guidelines for network operators on mitigating the risks identified in this draft. |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-12.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, Lorenzo Fedi |
| | Working Group: |
IP Performance Measurement (ippm) |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. |
| | Use of SHA-3 in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec |
| |
|
This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. |
| | Best Practices for CMS SignedData with Regards to Signed Attributes |
| |
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists best practices and mitigations for such a vulnerability. |
| | Supporting In Situ Operations,Administration and Maintenance Using MPLS Network Actions |
| |
| | draft-ietf-mpls-mna-ioam-04.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Rakesh Gandhi, Greg Mirsky, Tony Li, Haoyu Song, Bin Wen |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and record the operational state and telemetry information using, for example, Pre- allocated, Proof-of-Transit, Edge-To-Edge or Incremental IOAM Options, that can be used to calculate various performance metrics. RFC 9326 defined the IOAM Direct Export (IOAM-DEX) Option in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy on each node along the path. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transfer data needed for these actions. This document explores the MNA mechanisms to collect and transport the on-path operational state, and telemetry information IOAM data fields, including IOAM-DEX Option. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-ietf-mpls-mna-ps-hdr-04.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data-specific requirements found in RFC 9613. This document follows the framework specified in RFC 9789. |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-24.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Alex Feng, Pierre Francois, Tianran Zhou, Thomas Graf, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-10.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-09.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | TMCH Functional Specification Update |
| |
|
This document describes updates to the functional specification of the Trademark Clearing House, among them a new verison of the trademark claims notice. |
| | Internet 2.0: An Intent-Aware,AI-Native Extension of the Web |
| |
|
This document proposes Internet 2.0, an AI-native extension of the traditional web architecture. Unlike the current internet—which is designed primarily for document retrieval—Internet 2.0 enables distributed model discovery, intent-based routing, and protocol-level AI interaction. Core components include HTTP+AI, an AI-aware extension to HTTP; the Model Resolution Network (MRN), an AI-native analogue to DNS; and the AI-Aware Browser, a new class of client optimized for intelligent interaction rather than document traversal. This architecture treats AI models as first-class network entities and provides a foundation for a decentralized, semantic, and privacy- preserving AI layer on the internet. |
| | Authenticated Cache-Expiration Opcode (EXPIRE) |
| |
|
This document defines a new DNS message opcode, EXPIRE, which enables an authenticated authoritative operator to request immediate deletion of a specific RRset from a resolver's cache. EXPIRE messages may be authenticated either through DNSSEC signatures or through resolver control-channel authentication (for example TSIG, mutually authenticated TLS, IPsec, or local trust policy). EXPIRE applies only to resolver cache and MUST NOT modify authoritative data. Resolvers validate authority, apply mandatory replay protection using SOA serials when available or equivalent replay-mitigation mechanisms, and flush the targeted RRset upon successful validation. EXPIRE provides a deterministic, authenticated mechanism for cache rollback and correction across both signed (DNSSEC) and unsigned (internal) DNS deployments. |
| | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
|
This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration ("zeroconf") networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| |
|
| |
| | 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. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. |
| | 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. 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/ietf-scitt/draft-birkholz-cose-cometre-ccf- profile. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. |
| | The HiAE Authenticated Encryption Algorithm |
| |
| | draft-pham-cfrg-hiae-05.txt |
| | Date: |
13/11/2025 |
| | Authors: |
Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes HiAE, a high-throughput authenticated encryption algorithm designed for next-generation wireless systems (6G) and high-speed data transmission applications. 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/hiae-aead/draft-pham-hiae. |
| | QMux |
| |
| | draft-opik-quic-qmux-01.txt |
| | Date: |
13/11/2025 |
| | Authors: |
Kazuho Oku, Lucas Pardue, Jana Iyengar, Eric Kinnear |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-opik-quic-qmux. |
| | Dynamic Attestation for AI Agent Communication |
| |
|
This document describes a use case for conveying remote attestation information in association with Transport Layer Security (TLS) sessions in the context of AI agent communication. It focuses on long-lived secure channel sessions where an AI agent runtime posture, covering the platform Trusted Computing Base (TCB), agent manifest (models, tools and policies) and committed runtime context, can change frequently and unpredictably. The document highlights requirements for dynamic attestation so that relying parties can base authorization decisions on the current runtime posture of the communicating agent. |
| | DKIM2 Recipient and Next Domain Signing |
| |
|
This document proposes using the DKIM2 ESMTP extension to pass a signature for each intended recipient through the SMTP session rather than splitting email at the time of signing. This approach meets the DKIM2 objective of preventing email replay, while also preserving existing SMTP delivery logic, maintaining compatibility with DKIM and avoiding multiple calls to the DKIM2 filter. Also proposed is a method of signing the next domain in the DKIM2 chain of custody independently from the DKIM2-Signature. As per RFC5321, "... each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs". The requirements outlined herein ensure the majority of DKIM2 logic can be implemented within filters or supporting code, with only minimal and isolated changes in SMTP code. |
| | QUIC Idle Timeout Update |
| |
|
QUIC supports an idle timeout for connections, which can be negotiated once during the connection handshake. This document defines QUIC extension frames that permit either endpoint to initiate an update to the idle timeout value. |
| | Fragment Header for PREOF |
| |
|
This document re-use IPv6 Fragment Header to support DetNet Packet Replication, Elimination, and Ordering Functions (PREOF). |
| | Tracing process in IPv6 VPN Tunneling Networks |
| |
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-14.txt |
| | Date: |
13/11/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. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-ietf-opsawg-rfc5706bis-00.txt |
| | Date: |
13/11/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when defining New Protocols or Protocol Extensions. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream. |
| | 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. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a Routing Protocol for Low- Power and Lossy Networks (RPL) Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| | 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, to deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as listed in Section 5.3 Section 5.2 Section 5.3 Section 5.4 Section 5.5 - the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections. |
| |
|
| |
| | Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events |
| |
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, RFC 8106, and RFC 9096. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | BGP Operations and Security |
| |
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability requirements that can and should be ensured to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454, several developments and changes in operational practice took place that warrant an update of these best current practices. This document obsoletes RFC7454, focusing on the overall goals, and providing a less implementation centric set of best practices. This document describes security requirements and goals when operating BGP for exchanging routing information with other networks, and explicitly does not focus on specific technical implementations and requirements. |
| | Incremental Forwarding of HTTP Messages |
| |
|
This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. |
| | Problem Statement and Use Cases of Application-aware Networking (APN) |
| |
|
Network operators are facing the challenge of providing better network services for users. As the ever-developing 5G and industrial verticals evolve, more and more services that have diverse network requirements such as ultra-low latency and high reliability are emerging, and therefore differentiated service treatment is desired by users. On the other hand, as network technologies such as Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep evolving, the network has the capability to provide more fine- granularity differentiated services. However, network operators are typically unaware of the applications that are traversing their network infrastructure, which means that not very effective differentiated service treatment can be provided to the traffic flows. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network satisfying the fine- granularity requirements. This document analyzes the existing problems caused by lack of service awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) framework. |
| | Use cases of Application-aware Networking (APN) in Edge Computing |
| |
|
The ever-emerging new services are imposing more and more highly demanding requirements on the network. However, the current deployments could not fully accommodate those requirements due to limited capabilities. For example, it is difficult to utilize the traditional centralized deployment mode to meet the low-latency demand of some latency-sensitive applications. Moreover, the total amount of centralized service data is growing exponentially, which brings great pressure on the network bandwidth. There has been a clear trend that decentralized sites comprising of computing and storage resources are deployed at various locations to provide services. In particular, when the sites are deployed at the network edge, i.e. the Edge Computing, it can better handle the business needs of the users nearby, which provides the possibilities to provide differentiated network and computing services. In order to achieve the full benefits of the edge computing, it actually implies a precondition that the network should be aware of the applications' requirements in order to steer their traffic to the network paths that can satisfy their requirements. Application-aware networking (APN) aims to accommodate the edge services' needs, fully releasing the benefits of the edge computing. This document describes the various application scenarios in edge computing to which the APN can be beneficial, including augmented reality, cloud gaming and remote control, which empowers the video business, users interaction business and user-device interaction business. In those scenarios, APN can identify the specific requirements of edge computing applications on the network, process close to the users, provide SLA guaranteed network services such as low latency and high reliability. |
| | Use cases of Application-aware Networking (APN) in Game Acceleration |
| |
|
With the development of the Internet, game industry has risen rapidly, from handheld game consoles to PC games and mobile games. The types of games are diversified, while the number of game users is increasing year by year. The game market is maturing quickly. Nowadays, the scale of game users is large and they belong to the easy-to-consume groups. Among all the games, those require frequent interactions and involve video streaming usually have highly demanding requirements on the network in terms of guaranteed network latency and reliability. Therefore, from the aspect of ensuring better gaming experience, it is desirable of differentiating the particular gaming application flows and providing high-priority network services for those demanding gamers. This document describes the game acceleration scenarios using Application-aware Networking (APN) technology. In these scenarios, APN can identify the specific requirements of particular gaming applications, steer the flows to the game processors close to the users, and provide SLA guaranteed network services such as low latency and high reliability. |
| | Usage scenarios of Application-aware Networking (APN) for SD-WAN |
| |
|
This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a application group, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability. |
| | Application-aware Networking (APN) Header |
| |
| | draft-li-apn-header-05.txt |
| | Date: |
12/11/2025 |
| | Authors: |
Zhenbin Li, Shuai Zhang, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the application-aware networking (APN) header which can be used in a variety of data planes. |
| | Extension of Application-aware Networking (APN) Framework for Application Side |
| |
|
The Application-aware Networking (APN) framework defines that application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. This document defines the extension of the APN framework for the application side. In this extension, the APN resources of an APN domain is allocated to applications which compose and encapsulate the APN attribute in packets. When the network devices in the APN domain receive the packets carrying APN attribute, they can directly provide fine-granular traffic operations according to these APN attributes in the packets. |
| | Application Aware Computing Network |
| |
|
This document describes a solution framework that adheres to the CATS framework. The solution uses APN as part of the CATS service identifier and flow identifier. |
| | AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3 and QUIC |
| |
|
This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. 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-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. |
| | Application-aware Networking (APN) Framework |
| |
| | draft-li-rtgwg-apn-framework-01.txt |
| | Date: |
12/11/2025 |
| | Authors: |
Zhenbin Li, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. |
| | Application-aware IPv6 Networking (APN6) Encapsulation |
| |
|
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the APN header and its encapsulation in the IPv6 data plane. |
| | Route Origin Registry Problem Statement |
| |
|
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin AS (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry. |
| | DS support for private DNSSEC algorithms |
| |
|
Extend the DS digest field of the DS record to identify the private DNSSEC algorithm of the DNSKEY matching the DS record. |
| | 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. |
| | Media over QUIC - Hang |
| |
|
Hang is a real-time conferencing protocol built on top of moq-lite. A room consists of multiple participants who publish media tracks. All updates are live, such as a change in participants or media tracks. |
| | Media over QUIC - Lite |
| |
|
moq-lite is designed to fanout live content 1->N across the internet. It leverages QUIC to prioritize important content, avoiding head-of- line blocking while respecting encoding dependencies. While primarily designed for media, the transport is payload agnostic and can be proxied by relays/CDNs without knowledge of codecs, containers, or encryption keys. |
| | APN Scope and Gap Analysis |
| |
|
The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an attribute allowing the implementation of fine-grain user group-level and application group- level requirements in the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, for example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to efficiently realize this composite network service provisioning along the path. This document further clarifies the scope of the APN work and describes the solution gap analysis. |
| | APN Security and Privacy Considerations |
| |
|
Application-aware Networking (APN) aims to convey Application-aware Information (APN attribute) including APN ID and APN parameters indicating application group-level and user group-level requirements along with the data packets into the network and enable the network to provide corresponding fine-granular network services. There have been challenges of the privacy and security issues that could potentially be introduced by conveying the APN attribute into the network. This document describes the security and privacy considerations of APN in various possible scenarios wherein APN will be deployed. |
| | Dissemination of BGP Flow Specification Rules for APN |
| |
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute including APN ID and/or APN Parameters. The dynamic Flow Spec mechanism for APN is designed for the new applications of traffic filtering in an APN domain as well as the traffic control and actions at the policy enforcement points in this domain. These applications require coordination among the ASes within a service provider. This document specifies a new BGP Flow Spec Component Type in order to support APN traffic filtering. The match field is the APN ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsulation when matched to the corresponding Flow Spec rules. |
| | A YANG Model for Application-aware Networking (APN) |
| |
|
Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute (incl. APN ID and/or APN Parameters) to enable fine grained service provisioning. This document defines a YANG module for APN. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | Variable Length Node Data Field Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
|
The purpose of this memo is to describe a new IOAM Node Data Field type, called Flex Field, for In-Situ Operations, Administration, and Maintenance (IOAM). This option type, under IOAM Trace Option-Types will allow one to append variable length node data in an IOAM packet, along a network path. |
| |
|
| |
| | 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. |
| | Concrete Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. |
| | Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE |
| |
| | draft-ietf-hpke-pq-03.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Richard Barnes, Deirdre Connolly |
| | Working Group: |
HPKE Publication, Kept Efficient (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. |
| | Early IANA Code Point Allocation for IETF Stream Internet-Drafts |
| |
|
This memo describes the requirements for securing IANA code point assignments before RFC publication. In particular, it describes the "early allocation" process that allows for temporary but renewable allocations from registries that would ordinarily require an IESG- approved Internet-Draft: primarily, registries maintained in accordance with the "Standards Action," "IETF Review," "RFC Required," and, in some cases, "Specification Required" policies described in draft-ietf-ianabis-rfc8126bis. This process can be used when code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication. The procedures in this document are intended to apply only to IETF Stream documents. This document obsoletes RFC 7120. |
| | BGP Extension for SR-MPLS Entropy Label Position |
| |
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. |
| | 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. |
| | IMAP Extensions Suggestions |
| |
|
This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. |
| | PCEP Extensions for Performance Measurements with Stateful PCE for MPLS-TE and SR-TE LSPs |
| |
| | draft-gandhi-pce-pm-10.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Rakesh Gandhi, Bin Wen, Colby Barth, Dhruv Dhody |
| | Working Group: |
Individual Submissions (none) |
|
In certain networks, network performance data such as packet loss, delay and delay variation as well as bandwidth utilization are critical measures for Traffic Engineering (TE). This data provides operators the characteristics of their networks for performance evaluation that is required to ensure the Service Level Agreements (SLAs). The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs') requests. The Stateful PCE extensions allow Stateful control of Traffic Engineering Paths using PCEP for RSVP and Segment Routing (SR). This document describes PCEP extensions for enabling and reporting end-to-end performance measurements and liveness detection for both PCE-Initiated and PCC-Initiated LSPs for RSVP-TE and SR-TE (for MPLS and IPv6 data planes) to an Active Stateful PCE. |
| | RPL DIS Modifications and Use Cases |
| |
|
This document augments [RFC6550] by defining new DODAG Information Solicitation (DIS) flags and options that enable a RPL node to exert finer control over how neighboring RPL routers respond to its DIO solicitations. In addition, this document describes several use cases that motivate these DIS extensions and illustrate scenarios in which enhanced control of DIO responses improves network efficiency, responsiveness, and robustness. |
| | Signaling Composite Candidate Path of SR Policy using BGP-LS |
| |
|
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 specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. |
| | Dangerous Labels in DNS and E-mail |
| |
|
This document establishes registries that list known security- sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. |
| | Asset Schema Architecture for Asset Exchange |
| |
|
A management architecture for asset schemas and profiles is needed to enable entities in the tokenized assets ecosystem to instantiate tokens within one or more asset networks. An asset network may be constrained to support only a select class or type of token to be present in the network. In the SATP protocol, the receiving gateway at the destination network is assumed in its preparatory stages to evaluate the transfer request of a tokenized asset from the sending gateway at the origin network. In order to evaluate the proposed transfer, the receiving gateway must have access to the asset definition schema upon which the token was based in the origin network. The current document discusses the management architecture for the asset definition schema and the schema-profiles derived from the definition schema |
| | LSP Ping/Traceroute for Prefix SID in Multi-Algorithm/Multi-Topology Networks |
| |
| | draft-ali-mpls-algo-mt-oam-02.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Zafar Ali, Deepti Rathi, Shraddha Hegde, Changwang Lin, Jie Dong |
| | Working Group: |
Individual Submissions (none) |
|
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] works well in single topology, single algorithm deployments where each Prefix SID is only associated with a single IP prefix. In multi-topology networks, or networks deploying multiple algorithms for the same IP Prefix, MPLS echo request needs to carry additional information in the Target FEC Stack sub-TLVs to properly validate IGP Prefix SID. This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix Segment ID FEC sub-TLVs to also include algorithm identification while maintaining backwards compatibility. This document also introduces new Target FEC Stack sub-TLVs for Prefix SID validation in multi-topology networks. |
| | Test Battery for Opus ML Codec Extensions |
| |
|
This document proposes methodology and data for evaluation of machine learning (ML) codec extensions, such as the deep audio redundancy (DRED), within the Opus codec (RFC6716). |
| | The 'donau' URI scheme for validation of donation statements. |
| |
| | draft-grothoff-donau-02.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Christian Grothoff, Emmanuel Benoist, Bohdan Potuzhnyi, Florian Dold |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the 'donau' Uniform Resource Identifier (URI) scheme for triggering interactions with a validator for Donau donation statements. This URI scheme allows applications to trigger interactions with a Donau validator. A Donau validator is typically run by a tax authority to validate tax records from citizens that made donations to a charity that supports the Donau protocol. The Donau validator will receive 'donau' URIs representing the sum of donations a taxpayer made to recognized charities over a year. Donors would submit 'donau' URLs (or QR codes with 'donau' URLs) to tax authorities to have their donations recognized by the tax authority as tax-deductible expenditures. The application logic to verify the validity of the donation is triggered by 'donau' URIs. The validator application would then typically confirm to the tax official the validity of the signature encoded in the URI and show the total amount donated as well as the taxpayer identification number and the year of the donation. Multiple URIs could be submitted per donor, and the application can correctly determine which submissions are cumulative and which ones are redundant. This specification only covers the syntax of the 'donau' URI scheme and excludes details on the protocol(s) that would allow taxpayers to donate to recognized charities to obtain these suitable signed donation statements. While a privacy-preserving protocol to obtain such statements exists within the context of the GNU Taler protocol suite, other protocols could be developed in the future and still yield compatible 'donau' URIs as the URI scheme is reasonably generic. The validation tool will be registered for all donau:// URIs. Since each taxation authority will typically use a different domain, it will not be feasible to encode all the domains of tax authorities servers inside the validation tool. Hence a new URI scheme is needed that will trigger the validation tool for any domain name. |
| | BGP extensions for SRv6/MPLS Transport Interworking |
| |
|
This document defines the BGP extensions required to provide transport interworking between SRv6 and MPLS in SRv6 deployment. |
| | Agents Networking Scenarios in Enterprise and Broadband Networks |
| |
|
This document describes agents networking scenarios in enterprise and home broadband networks. These scenarios differ from mobile networks and Internet scenarios. Since the agentic service is still at the emerging stage, especially in enterprise and home broadband networks, the scenarios are mostly based on reasonable assumptions. |
| | AI Agent to Tool (A2T) Protocol |
| |
|
This document defines a protocol that facilitates integration of tools into the design and run-time operations of AI Agents. The focus is on enterprise AI agents that need to make use of APIs exposed by third party providers. This protocol, called the Agent- to-Tool (A2T) Protocol defines an OpenAI spec that has two principle features - enumeration of tools and invocation of tools. The enumeration API enables a human - the AI Agent designer employed by the enterprise - to select and include tools from third-party vendors into operating procedures (also known as skills or instructions) which direct the behavior of AI Agents, including how and when to invoke those tools. The enumeration API can also be used (optionally) at run-time for the LLM to obtain tool descriptions. The second feature of the API - invocation - allows the AI Agent executor to perform the inter-domain invocation of the tool at run time. By standardizing these two API functions, the time and cost of integration of Internet APIs into AI Agents can be reduced. |
| | A Review of RADIUS Security and Privacy |
| |
|
This document provides a comprehensive review of security issues related to the RADIUS Protocol. This review motivates the changes to RADIUS security which are made in [I-D.ietf-radext-deprecating-radius]. |
| | CDN Node Selection Enhancement using Anycast and QUIC |
| |
|
Content Delivery Networks (CDNs) are critical infrastructure for improving user experience by serving content from geographically proximate servers. Traditional CDN node selection mechanisms, such as DNS-based redirection and BGP-based anycast, primarily rely on network proximity and often lack awareness of server load or specific application requirements. This can lead to suboptimal performance and inefficient resource utilization. This document proposes an enhanced mechanism for dynamic CDN node selection that leverages IPv4/v6 anycast, BGP, and the QUIC transport protocol. The proposed solution enables CDN nodes to advertise or withdraw their anycast routes based on real-time load and link quality. Furthermore, it defines a mechanism for clients to signal their service requirements (e.g., high-compute, low-latency, or high- bandwidth) and for servers to redirect clients to more optimal nodes using QUIC's connection migration capabilities. This allows for a more intelligent, load-aware, and application-aware CDN node selection process. |
| | Discovering x402 Resources via DNS TXT Records |
| |
|
This document defines a DNS-based discovery mechanism for locating x402 payment resources associated with a domain. Domains publish one or more _x402 TXT records containing URLs where x402-compatible clients can obtain resource manifests and metadata over HTTPS. The goal is to provide a lightweight, cache-friendly discovery vector that enables automated payment negotiation using the x402 protocol while keeping DNS records static and non-sensitive. |
| | vCon Zip Bundle |
| |
|
This document defines the vCon Zip Bundle (.vconz) file format for packaging one or more vCon conversation data containers with their associated media files into a single, self-contained ZIP archive. While vCons support external file references via HTTPS URLs with content hashes, these dependencies create availability and portability challenges. The vCon Zip Bundle addresses this through a standardized archive format that includes all referenced files, supports multiple vCons with automatic deduplication based on content hashes, preserves data integrity through hash verification, and enables offline processing. This specification maintains full compatibility with all vCon security forms (unsigned, signed, encrypted) as defined in the vCon core specification. |
| | SD-JWT-based Verifiable Credentials (SD-JWT VC) |
| |
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) |
| |
| | draft-ietf-pce-pcep-nrp-00.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad |
| | Working Group: |
Path Computation Element (pce) |
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. |
| | QUIC Acknowledgment Frequency |
| |
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. |
| | Deprecating Insecure Practices in RADIUS |
| |
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. |
| | Applicability & Manageability Considerations for SCONE |
| |
|
This document describes the Applicability and Manageability considerations for providing throughput guidance to application endpoints. This guidance is specifically addressed within the context of telecommunications service provider networks utilizing the Standard Communication with Network Elements (SCONE) protocol. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-09.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| | Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs) |
| |
|
This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. This document obsoletes RFC6791, Stateless Source Address Mapping for ICMPv6 Packets and updates IP/ICMP Translation Algorithm (RFC7915). |
| |
|
| |
| | 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. |
| | 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. |
| | Ownership and licensing statements in YANG |
| |
|
This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further network request. |
| | Extension Formatting for the Opus Codec |
| |
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-42.txt |
| | Date: |
05/11/2025 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows |
| |
|
This specification defines the web message response mode that authorization servers use for transmitting authorization response parameters via the user-agent's postMessage API to the client. This mode is intended for authorization flows that use secondary windows, which are well-suited for browser-based applications. |
| | BGP SR Policy Extensions for Administrative Flags |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | 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. |
| | Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | Knowledge Graph for Network Traffic Monitoring and Analysis |
| |
|
This document extends the knowledge graph framework specifically to the traffic management domain, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. |
| | The tag-42 profile of CBOR |
| |
|
This document defines a very narrow profile of CBOR intended for use with the special tag 42. Like the earlier internet-draft submitted under the name "CBOR Core," much of its design dates to the first CBOR RFC and predates much of the layered approach to determinism and profiling in later years. Also like "CBOR/c", CBOR-42 can be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR-42 objects link to one another by hash-based identifiers tagged "42", deterministic encoding is mandated to verify dereferenced links and encode new ones. |
| | Transaction Tokens For Agents |
| |
|
This document specifies an extension to the OAuth Transaction Tokens framework (https://drafts.oauth.net/oauth-transaction-tokens/draft- ietf-oauth-transaction-tokens.html) to support agent context propagation within Transaction Tokens for agent-based workloads. The extension defines two new context fields: 'actor' and 'principal'. The 'actor' field identifies the agent performing the action, while the 'principal' field identifies the human or system entity that initiated the agent's action. For autonomous agents operating independently, the 'principal' field MAY be omitted. These additional context fields enable services within the call graph to make more granular access control decisions, thereby enhancing security. |
| | Enhancement for Monitoring VRF's Loc-RIB |
| |
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a VPN route information to zero, and sets the Peer Distinguisher value of a VPN route information to the route distinguisher or unique locally defined value of the particular instance the Loc-RIB belongs to. This document introduces the option to communicate the Remote VRF Information from which a VPN route was received when reporting that VPN route information with BMP Loc-RIB. |
| | Agent Considerations |
| |
|
IETF specifications provide the basis for technical implementation in several programming languages. An IETF specification that provides appropriate guidance to artificial intelligence (AI) agents, can enable such agents to consume specifiction and generate code from it. This documents defines the use of an Agent Consideration section that is in support of code generation including the use of agentcards, guidance on authorship, examples and their annotation for code generation, as well as language specific guidance for the production of media-types. The Agent Consideration defined in this document can be added to any Internet-Draft that includes normative language and sufficiant expressive examples derived from an included data model and protocol interaction defintions. |
| | Using MUD in Constrained Environments |
| |
|
This document specifies additional ways for discovering and emitting Manufacturer Usage Descriptions (MUD), especially in constrained environments, utilizing the Constrained Application Protocol (CoAP), CoRE Resource Discovery, and CBOR Web Tokens. |
| | Transmission of IPv6 over Multidrop Serial Bus/Token Passing (MS/TP) Networks |
| |
|
Multidrop Serial Bus/Token Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. It obsoletes RFC 8163. |
| | Passive Hot Reload for Web Servers |
| |
|
This document defines a passive, file-based mechanism for automatic hot reloading of configuration files and TLS certificates in web servers. Unlike traditional web servers that require explicit reload commands, this design uses file modification time (mtime) to detect changes and reloads in memory automatically. |
| | Age Verification Architecture |
| |
| | draft-knodel-age-arch-00.txt |
| | Date: |
05/11/2025 |
| | Authors: |
Mallory Knodel, Gianpaolo Scalone, Thomas Newton |
| | Working Group: |
Individual Submissions (none) |
|
This document describes solution-agnostic and technology-neutral schema for how various intermediaries can gate content and services based on age. The analysis of the architecture is done based on the effectiveness of permitting or restricting access based on age. The document concludes with recommendations as well as critical privacy, security and human rights considerations. |
| | Remote Attestation for Trustworthy Workload Identity |
| |
|
Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy Workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. |
| | OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-Of Authorization |
| |
|
This draft proposes an authorization method for task-oriented multi- AI agent collaboration scenarios, where a leading agent coordinates sub-AI agents to complete complex tasks. The method extends the OAuth 2.0 protocol by adding an optional applier_id field, enabling the leading agent to apply for access tokens on behalf of other sub- AI agents. This approach greatly simplifies the sub-AI agents' authorization process, avoids efficiency loss from repeated interactions between multiple sub-AI agents and the authorization server, meanwhile maintaining full compatibility with existing OAuth 2.0 workflows. |
| | Update to Automatic Bandwidth Adjustment Procedure of Stateful PCE for MPLS-TE and SR-TE LSPs |
| |
|
The Stateful PCE extensions allow Stateful control of Traffic Engineering (TE) LSPs using PCEP for RSVP-TE and Segment Routing (SR) (for both MPLS and IPv6 Data planes) for both PCE-Initiated and PCC- Initiated LSPs. Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. In addition, this document updates RFC 8733 by applying the PCEP extensions to SR-TE LSPs (for both MPLS and IPv6 Data planes), in addition to MPLS-TE LSPs. |
| | Reference Interaction Models for Remote Attestation Procedures |
| |
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-ietf-regext-epp-quic-02.txt |
| | Date: |
05/11/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. |
| |
|
| |
| | Encrypted DNS Server Redirection |
| |
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. |
| | Multiple Loss Ratio Search |
| |
|
This document describes an alternative to "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) throughput by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and improve result repeatability and comparability. MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software-based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs purpose-built ASIC / NPU / FPGA hardware. |
| | Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE |
| |
|
This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). 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/tplooker/draft-ietf-cose-bls-key-representations. |
| | Digital Emblems - Use Cases and Requirements |
| |
| | draft-ietf-diem-requirements-00.txt |
| | Date: |
04/11/2025 |
| | Authors: |
Casey Deccio, Rahel Fainchtein, Felix Linker, Jim Reid, Alex Rosenberg, Allison Mankin |
| | Working Group: |
Digital Emblems (diem) |
|
TODO Abstract |
| | Hybrid Public Key Encryption |
| |
| | draft-ietf-hpke-hpke-02.txt |
| | Date: |
04/11/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. |
| | REST API Media Types |
| |
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. |
| | Terminology for Constrained-Node Networks |
| |
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. |
| | Authorized update to MUD URLs |
| |
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| | 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. |
| | JSON Proof Token and CBOR Proof Token |
| |
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. |
| | JSON Web Proof |
| |
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a Presentation Header to prevent replay. |
| | JSON Proof Algorithms |
| |
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. |
| | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
| | draft-ietf-lamps-macaddress-on-00.txt |
| | Date: |
04/11/2025 |
| | Authors: |
Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines a new otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a layer-2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension. |
| | Mail Autoconfig |
| |
|
A protocol that allows email applications to set up mail accounts and related accounts with only the email address and password. It defines how service providers can publish the account configuration, so that email applications can automatically find a working configuration. It reduces setup friction for their users, and calls to the support for the service provider. Although the discovery process starts with an email address, the protocol is not limited setting up email accounts, but can also set up calendar, contact and file sync, video conference accounts and other accounts that are connected to the same user account. This protocol uses a well-known address and DNS lookups, based on the email address domain, to find the XML configuration file for the service provider. |
| | ML-KEM and Hybrid Cipher Suites for Messaging Layer Security |
| |
|
This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | NTS extensions for enabling pools |
| |
| | draft-venhoek-nts-pool-04.txt |
| | Date: |
04/11/2025 |
| | Authors: |
David Venhoek, Folkert de Vries, Marc Schoolderman |
| | Working Group: |
Individual Submissions (none) |
|
The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Mobile nodes that operate in air/land/sea/space domains (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) 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 supports mobile node coordination with a network-based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) and mobility service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI use IPv6 Neighbor Discovery (IPv6 ND) 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. 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. |
| | VESPER - Framework for VErifiable STI Personas |
| |
|
This document formalizes a profile and a framework for the use of delegate certificates and authority tokens to strengthen the association between telephone number assignments and the entities that have the authoritative right to use them on the telephone network. It defines a model in which the TNAuthList Authority Token serves as a trusted representation of telephone number assignment and right-to-use (RTU), anchored by a Notary Agent that logs these associations through verifiable transparency mechanisms. The framework also extends the use of authority tokens to support other PASSporT claims like Rich Call Data (RCD) by defining a role for JWTClaimConstraints Authority Tokens. These tokens are issued by authoritative or recognized and vetted claim agents within the ecosystem to assert information associated with the entity assigned a telephone number. The Notary Agent plays a critical role in recording these claims and their provenance, enhancing transparency and accountability. Delegate certificates encapsulate and incorporate both the telephone number and associated information validated via authority tokens to the certification authority issuing them, binding them to the authenticated telephone number of the calling party. These certificates are published to a certificate transparency log, enabling relying parties to independently verify the integrity and legitimacy of number use and related claims. The VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and the ACME authority token to formalizing a verifiable, auditable, and privacy-conscious foundation for associating telephone numbers with identifiable entities and assertion of associated metadata. |
| | Domain Related Group Support for EPP |
| |
|
This document defines an EPP extension allowing clients to learn about and manipulate related groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant. |
| | RADIUS over QUIC |
| |
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. |
| | A reference architecture for direct presentation credential flows |
| |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. 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/leifj/wallet-refarch. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM |
| |
|
Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the “harvest now and decrypt later” threat posed by cryptanalytically relevant quantum computers (CRQC). For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in the IKEv2 as an additional key exchange mechanism. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ] |
| | LDP Extensions for Flex-Algo |
| |
|
This document specifies extensions to LDP to support the use Flex- Algo, enabling Label Switched Paths (LSPs) to follow a specific Flex-Algo. |
| | PIM Reverse Path Forwarding (RPF) Vetor Conflict Resolution |
| |
|
[RFC7891] Section 7 defines the handling principles for PIM Join attributes with same type of RFF Vector and Explicit RFP Vector, but with different contents are received. However, it does not address scenarios where one downstream router includes a RFF Vector in its message while another does not. This leaves the handling of such conflicts unspecified. This document supplements the existing specifications by defining the processing rules for this specific conflict scenario. |
| | SCIM RoleAssignment Draft Specification v0.2 |
| |
|
SCIM 2.0 defines "roles" and "entitlements" attributes on the User resource, but it lacks a standardized way to bind roles to specific scopes such as projects, tenants, or groups. This gap forces organizations to rely on group sprawl or non-standard encodings, preventing true interoperability. This document introduces a new SCIM resource type, RoleAssignment, which models scoped role bindings as first-class records, enabling portable provisioning, lifecycle governance, and compliance visibility. |
| | VESPER Out-of-Band OOB |
| |
|
This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework in environments where SIP signaling is unavailable or unsuitable. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within SIP-based VoIP networks. These PASSporTs are signed with delegate certificates that were authorized for issuance by corresponding authority tokens, which represent the trust and validation of telephone number control and related claim information. Transparency features ensure that these authorizations are publicly auditable and cryptographically provable, supporting a higher standard of trust. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to-end accountability. The OOB mechanism serves as an alternative delivery path for PASSporTs in cases where end-to-end in-band SIP delivery is not possible, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. |
| | NTPv5 Algorithms |
| |
|
This document describes considerations of synchronisation algorithms with version 5 of the Network Time Protocol (NTP), and provides guidance on the use of NTP version 4's algorithms when used with NTP version 5. |
| | A CBOR Tag for Lossless Transport of IEEE-754 NaN Bit Patterns |
| |
|
IEEE-754 NaN formations are not numbers and have no equivalence class. They are not comparable to anything, including reflexively, and therefore each attribute - sign bit, signaling/quiet bit, payload bits, and representation width (binary16, binary32, binary64, binary128) - can carry meaning for an implementation. CBOR permits encoding NaNs as floating-point values, but generic processing, preferred serialization, and deterministic profiles may canonicalize or otherwise alter NaN encodings, losing information. This document defines a CBOR tag, colloquially "nan-bstr", whose content is a byte string carrying the exact IEEE-754 NaN bit pattern so that all attributes are preserved across encode/decode, enabling use cases like NaN boxing, platform-specific error signaling, diagnostics, and forensics. |
| | SONAR: Statistical Observation Network for Attestation and Reach |
| |
|
This document specifies SONAR (Statistical Observation Network for Attestation and Reach), a protocol for verifiable multicast delivery claims without trusted intermediaries. SONAR combines: (1) O(1) IP multicast efficiency versus O(N) unicast to detect cheating, (2) cryptoeconomic accountability via on-chain stake deposits, VRF-based unpredictable sampling, and blockchain attestations, and (3) ALTA- based real-time multicast authentication. SONAR separates content authentication from coverage verification: ALTA authenticates all packets with ~6% bandwidth overhead, while statistical coverage verification adds minimal overhead (320 KB challenge messages per 15-60 minute test period, 0.7-2.8 Kbps). Coverage estimation samples 0.1% of receivers using German Tank Problem inference. For privacy and cost efficiency at scale, zkSNARK proof aggregation (recommended for >1,000 sampled users) maintains O(1) on-chain verification cost, enabling populations exceeding 10^8 receivers. |
| | Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) |
| |
|
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using, the forthcoming, FIPS 206, the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | Use of the FN-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), as defined by NIST in FIPS 206, 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 FN-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier is provided. |
| | BPP |
| |
|
This document defines the Bitcoin Price Protocol (BPP), a lightweight, peer-to-peer protocol for synchronising a high-confidence Bitcoin price across untrusted networks. Modeled after the Network Time Protocol (NTP, RFC 5905), BPP enables any Internet host to obtain a volume-weighted median USD/BTC price that is accurate to within a few dollars and fresh to within a few seconds, without trusting any single exchange, oracle, or API provider. BPP is deliberately off-chain, runs over UDP/QUIC, and requires no blockchain interaction. It is suitable for wallets, trading bots, payment processors, DeFi front-ends, and hardware devices that need "NTP-grade" price agreement. |
| | Scale-Up Network Header (SUNH) |
| |
|
This document specifies a network header that is a type of compressed IPv4 or IPv6 header. The use case is high performance networking in limited domains, in particular in scale-up networks for AI where even modest packet overhead packet may be materially detrimental to overall performance. The SUNH network header provides three primary benefits: 1) It reduces the amount of on-the-wire protocol overhead, 2) It simplifies route lookup to be more efficient with lower latency, 3) It retains the properties and benefits of a Network Layer header including compatibility with deployed Ethernet switches and NICs. |
| | The ipn.arpa Zone and IPN DNS Operations |
| |
|
This document requests a DNS parent for IPN addresses, discusses the registration procedures and management of the DNS zone, as well as some operational recommendations. This document specifies that IPN addresses may have a DNS representation of the form 1.978879.ipn.arpa, for IPN node 1 under IPN Allocator 978879. This document also describes how this DNS structure can be useful in locating the Bundle Protocol (BP) Convergence Layer (CL) endpoint(s) of the BP Agent responsible for a given IPN address. |
| | Persistent Symmetric Keys in OpenPGP |
| |
|
This document defines a new packet and algorithm for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for message authentication using AEAD authentication tags. This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-ietf-pquip-hbs-state-01.txt |
| | Date: |
04/11/2025 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
Stateful Hash-Based Signature Schemes (Stateful HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large-scale quantum computers. Unlike conventional stateless digital signature schemes, Stateful HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on Stateful HBS. Management of the state of the Stateful HBS, including any handling of redundant key material, is a sensitive topic, 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. |
| | A reference architecture for direct presentation credential flows |
| |
| | draft-ietf-spice-vdcarch-00.txt |
| | Date: |
04/11/2025 |
| | Authors: |
Leif Johansson, Brent Zundel, Tim Cappalli |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. 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/leifj/wallet-refarch. |
| | OCSP Usage for Secure Telephone Identity Certificates |
| |
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. |
| | Short-Lived Certificates for Secure Telephone Identity |
| |
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation |
| |
| | draft-ietf-acme-dns-persist-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Shiloh Heurich, Henry Birge-Lee, Michael Slaughter |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi- tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/ Browser Forum Baseline Requirements. |
| | RTP Payload Format for V-DMC |
| |
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-21.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-19.txt |
| | Date: |
03/11/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. |
| | DKIM2 Header Definitions |
| |
|
This document describes the email header fields defined for DKIM2, and how they work togther to provide the required properties. This is an early draft, a work in progress. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. |
| | Intimate Partner Violence Digital Considerations |
| |
| | draft-irtf-hrpc-ipvc-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sofia Celi, Juliana Guerra, Mallory Knodel |
| | Working Group: |
Human Rights Protocol Considerations (hrpc) |
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These security compromises go beyond active and passive on-path attacks [RFC7624]. With a focus on protocols, the document describes tactics of the IPV attacker and potential counter-measures. |
| | LISP Virtual Private Networks (VPNs) |
| |
| | draft-ietf-lisp-vpn-13.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. |
| | CARP - a CMAF compliant implementation of WARP |
| |
|
This document updates [WARP] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to WARP. |
| | External Trace ID for Configuration Tracing |
| |
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| | Use Cases and Practices for Intent-Based Networking |
| |
| | draft-irtf-nmrg-ibn-usecases-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Kehan Yao, Danyang Chen, Jaehoon Jeong, Qin WU, Chungang Yang, Luis Contreras, Giuseppe Fioccola |
| | Working Group: |
Network Management (nmrg) |
|
This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learning and general learning are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. Finally, this document discusses three aspects for the deployment of IBN systems on the real world. They are Multi- Domain Deployment, Network Digital Twin, and IBN with Artificial Intelligence (AI). |
| | A Decent LISP Mapping System (LISP-Decent) |
| |
|
This draft describes how the LISP mapping system can be distributed for scale, decentralized for management and maintain trust among data-plane nodes. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | 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. |
| | Agreements To Fix Forwarding |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. |
| | OpenPGP HTTP Keyserver Protocol |
| |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
| | draft-cxx-ippm-ioamaggr-04.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger |
| | Working Group: |
Individual Submissions (none) |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but its length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using SCONE protocol signalling, it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | User Attributes in OpenPGP |
| |
|
This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information, which contained in QUIC Header, QUIC Frame and Stream that traffic is being forwarded along with. |
| | 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 proposes a robust, stateless challenge-response mechanism to authenticate ICMPv6 error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. 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. |
| | Requirements Analysis of System and Network for Large Language Model Inference Service |
| |
|
With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, such as vLLM, SGLang, Mooncake, etc. This paper investigates mainstream inference frameworks, summarizes their core design principle and research question, and analyzes the challenges and requirements they impose on network management. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. |
| | 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. |
| | ICMP Error Handling in SRv6 based VPN Networks |
| |
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). |
| | 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. |
| | Call Placement Service (CPS) URI Certificate Extension for STI Certificates |
| |
|
This document specifies a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers authorized in a STIR Delegate Certificate. The extension enables originators and verifiers of STIR PASSporTs to discover, with a single certificate lookup, where Out- of-Band (OOB) PASSporTs can be retrieved. The mechanism removes bilateral CPS provisioning, allows ecosystem-scale discovery backed by STI Certificate Transparency (STI-CT), and is fully backward compatible with existing STIR certificates and OOB APIs. |
| | DACP: Data Access and Collaboration Protocol |
| |
| | draft-shenzhihong-dacp-01.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Zhihong Shen, Xiaojie Zhu, Zhenjing CHENG, Ziang Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Data Access and Collaboration Protocol (DACP), a communication protocol designed to support cross-node, cross-process data access in scientific and distributed computing environments. DACP provides standardized streaming-based data interactions over the Arrow Flight protocol and defines a unified Streaming DataFrame (SDF) model, which acts as a high-performance abstraction for accessing and processing both structured and unstructured data. |
| | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
|
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. |
| | Generic Event Notification (GEN) for BGP Monitoring Protocol (BMP) |
| |
|
This document defines a new BMP message type: the Generic Event Notification (GEN). The BMP GEN message provides a flexible mechanism for reporting a wide variety of events related to BGP at different levels of hierarchy, such as routing instance, AFI/SAFI, or peer level. The BMP GEN message enables operators and automated systems to receive detailed context for operational events, such as policy triggers, administrative interventions, and state management notifications (e.g., RIB view unmonitor events). |
| | Agent Identity Managenment |
| |
|
This document specifies agent identity management in the Internet of Agents (IOA) system. It defines the descriptive requirements for agent identities, the agent registration process, the structure and assignment of agent identifiers, and the basic and extended identity management functions performed by the agent gateway based on the agent's descriptive information. |
| | Agents Networking Framework for Enterprise and Broadband |
| |
|
This document introduces agents networking framework and defines the core components of agent networking in enterprise and broadband, as well as typical interactions among these key components. |
| | A Profile for Traffic Origin Authorizations (TOAs) |
| |
| | draft-qin-savnet-toa-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Lancheng Qin, Ben Maddison, Dan Li, Igor Lubashev |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. |
| | Quantum Datagram Control Protocol (QDCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qdcp-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | External Relationship model for SIMAP |
| |
|
This document defines a SIMAP feature that enables modeling of external relationships between SIMAP entities and resources outside their core data models. It provides a templating approach to describe queries for external information, and an approach to link them to network elements. |
| | Rapid Startup of Congestion Control |
| |
|
This document defines Rapid Start, a congestion-control startup algorithm that grows the window by 3× per RTT until queue buildup is observed, so that a sender can reach the path BDP faster than with classic 2× slow start. When congestion is observed, Rapid Start immediately scales the window relative to the bytes that have passed through the bottleneck and then hands over to normal recovery and congestion avoidance. |
| | A method for describing changes to emails |
| |
|
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. This method also captures hashes of important features of the message, allowing validation that the changes were described correctly, and allowing a signature which covers the Mail-Version header to, by extention, ensure that the important content of the message is unchanged. |
| | Scrubbing BGP ORIGIN Attribute |
| |
|
The BGP Origin attribute in its original meaning has been out of use for years. Yet, the BGP Origin attribute has high priority in the best route selection algorithm, right after the AS Path length, and it's being used inconsistently over the Internet to manipulate the route preference. This document updates RFC 4271 and RFC 7606 by making the BGP Origin attribute half-optional and explicitly allowing its scrubbing to zero (IGP). |
| | Phishing-Resistant Phone Number Attestation for MFA |
| |
|
This draft introduces a phishing-resistant phone number attestation mechanism for multi-factor authentication (MFA). Conceptually similar to WebAuthn, it uses origin-bound cryptographic challenges to ensure that users only attest ownership of their phone numbers to legitimate relying parties. The protocol leverages network-operator- issued verifiable credentials (VCs) that cryptographically bind phone number ownership to a user's device. Applications present origin- scoped challenges that users sign using their VC, ensuring secure, domain-specific authentication and mitigating replay, relay, and phishing attacks- without relying on SMS-based one-time passwords (OTPs). |
| | Semantic Routing Architecture for AI Agents Communication |
| |
|
This document introduces an Semantic Routing (SR) Architecture for enabling intelligent, semantic-driven communication among AI Agents. Unlike traditional IP-based routing or service mesh approaches, SRA leverages application-layer semantics — including service identity, intent vectors, and trust scores — to guide routing decisions dynamically. The architecture supports intent-driven task collaboration, trust-aware policy enforcement, and adaptive routing for multi-agent environments. SRA enables the network to evolve from a passive transport layer to an intelligent collaboration substrate supporting multi-agent coordination and cognitive networking. |
| | Routing Architecture for Satellite Networks Based on Hierarchical Structure |
| |
|
The satellite routing is the premis to ensure that the satellite network provides end-to-end stable service covering the whole globe. However, the mature terrestrial network technologies are difficult to directly apply to the satellite network because of the highly dynamic network topology and the limited on-board resources. In view of this challenge, this document presents a hierarchical routing architecture for satellite networks based on the prediction topology between satellites or satellites and ground stations. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-ietf-nvo3-rfc7348bis-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This documents specifies 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 document obsoletes RFC7348 which documented the deployed VXLAN protocol for the benefit of the Internet community, and moves the VXLAN specification to the IETF document stream, allowing for the creation of extensions to VXLAN that require additions to the VXLAN header and their registration with IANA. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
| | draft-ietf-opsawg-yang-provenance-03.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integritu of datasets and/or data streams. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps |
| |
|
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-12.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ahmed Abdelsalam, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |
| | A well-known URI for publishing service parameters |
| |
| | draft-ietf-tls-wkech-11.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Stephen Farrell, Rich Salz, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record. |
| | Large Record Sizes for TLS and DTLS with Reduced Overhead |
| |
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^30 - 256 bytes, while reducing overhead. |
| | WIMSE Workload Credentials |
| |
| | draft-ietf-wimse-workload-creds-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Brian Campbell, Joseph Salowey, Arndt Schwenkschuster, Yaron Sheffer, Yaroslav Rosomakho |
| | 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 credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. |
| | WIMSE Workload Proof Token |
| |
| | draft-ietf-wimse-wpt-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Brian Campbell, Arndt Schwenkschuster |
| | 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 basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-level proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. |
| |
|
| |
| | Generic Address Assignment Option for 6LoWPAN Neighbor Discovery |
| |
| | draft-ietf-6lo-nd-gaao-08.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Luigi Iannone, David Lou, Adnan Rashid |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
| | draft-ietf-bmwg-powerbench-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, Gen Chen |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. |
| | BLS Signatures |
| |
| | draft-irtf-cfrg-bls-signature-06.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Dan Boneh, John Bradley, Sergey Gorbunov, Riad Wahby, Hoeteck Wee, Christopher Wood, Zhenfei Zhang |
| | Working Group: |
Crypto Forum (cfrg) |
|
BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. |
| | Pairing-Friendly Curves |
| |
|
Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. |
| | DKIM2 - signing the source and destination of every email |
| |
|
This memo provides a rationale for building a new email accountability mechanism, based on the lessons learned from implementing the ARC experiment from RFC 8617 and other experiences from email system operators. |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. 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/ietf-wg-dnsop/draft-ietf-dnsop-grease. |
| | BGP Next Hop Dependent Characteristics Attribute |
| |
| | draft-ietf-idr-nhc-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Bruno Decraene, Kireeti Kompella, Serge Krier, MOHANTY Satya, John Scudder, Kevin Wang, Bin Wen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. |
| | BGP Entropy Label Characteristic |
| |
| | draft-ietf-idr-elc-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Bin Wen, Kevin Wang, John Scudder, MOHANTY Satya, Serge Krier, Kireeti Kompella, Bruno Decraene |
| | Working Group: |
Inter-Domain Routing (idr) |
|
The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. |
| | IMAP OBJECTID Partial Implementation extention |
| |
|
This document extends the IMAP OBJECTID specification in RFC8474, which describes persistent identifiers for Mailboxes, Emails, and Threads in email. Some servers may be unable to provide persistent identifiers for some data types, but be able to provide them for others. This extension allows a server to specify that it can provide some objectids, without needing to implement all data types. |
| | Multicast YANG Data Model |
| |
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast streams. It provides a management view for network administrators to obtain information about multicast services. |
| | Multicast Redundant Ingress Router Failover |
| |
|
This document is intended to serve as a guide for multicast network operators of various replication technologies to evaluate the options and tradeoffs in deploying redundant ingress router failover. Section 5 of RFC9026 details the hot root standby solution for MVPN networks. Here we attempt to extend the discussion to cover additional multicast deployment solutions beyond MVPNs. This document compares cold, warm, and hot standby modes, listing their advantages, limitations and deployment considerations to help identify the appropriate solution for any network. |
| | 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. |
| | Remote Procedure Call over QUIC Version 1 |
| |
|
This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. |
| | Multi-Topology in PIM |
| |
| | draft-xz-pim-flex-algo-06.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Individual Submissions (none) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Supplement of BGP-LS Distribution for SR Policies and State |
| |
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags and a new sub-TLV are introduced in the SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. |
| | 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks |
| |
|
This document defines a new type of segment for Segment Routing, 4map6 segment, along with its corresponding End.4map6 endpoint behavior. This behavior performs stateless IPv4/IPv6 translation or encapsulation at PE nodes based on stateless mapping rules, thereby enabling the delivery of IPv4 services over an IPv6-only network. At the same time, the BGP Prefix-SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: 1. *Symmetric authentication protocol* - A protocol for the mutual recognition of entities based on a symmetric exchange of authentication messages through the mediation of Identity Providers (IdPs). It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - The IdPs network infrastructure that provides a secure environment for exchanging authentication messages. 3. *Custodian concept* - A special category of IdPs to protect physical identity and personal data. The generic IdP is called "*_trustee_*" and is only responsible for digital authentication, while the special IdP called "*_custodian_*" has the legal right to process the individual's real data and maintain the relationship with the digital identity. Custodian acts under the direct control of the authorities of the individual's country. |
| | IGP Flexible Algorithm with Time Constraint |
| |
|
IGP Flexible Algorithm allows IGPs to compute constraint-based paths over the network using different types of metrics or constraints. This document defines a new type of constraint called "Time Constraint", which can be used to control the time period during which a Flex-Algorithm takes effect for constraint-based path calculation. Such mechanism may be useful in network scenarios where either the traffic demand or the characteristics of the network varies as a function of time. The procedures of using Time Constraint in Flexible Algorithm is also described. |
| | Documenting and Managing DNSSEC Algorithm Lifecycles |
| |
|
Cryptographic algorithms for DNSSEC go through multiple phases during their lifetime. They are created, tested, adopted, used, and deprecated over a period of time. This RFC defines phases for the DNSSEC algorithm lifecycle, and it defines the criteria for moving from one phase to the next. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
This document proposes extension for ICMPv6 to detect data plane failures for EVPN over SRv6. |
| | Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation |
| |
|
This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations. |
| | Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol (ICMP) 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 proposes a robust, stateless challenge-response mechanism to authenticate ICMP error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of- Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per- challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMP. |
| | RPKI Terminology |
| |
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times be inconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. |
| | CBOR Encoding for HTTPS-based YANG Notifications Transport |
| |
|
This document extends [I-D.draft-ietf-netconf-https-notif] by introducing CBOR encoding for YANG notifications over HTTPS Transport in addition to the existing JSON and XML encoding schemes. |
| | Network File System version 4.2 COPY Operation Implementation Experience |
| |
|
This document describes the authors' experience implementing the NFSv4.2 COPY operation, as described in [RFC7862]. It then recommends and motivates updates to that document. This is not a normative document. |
| | RESTful Provisioning Protocol (RPP) |
| |
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. |
| | DNS-based Service Discovery for Computing-Aware Traffic Steering (CATS) |
| |
|
This document specifies how DNS-based Service Discovery (DNS-SD) can be used as a discovery and resolving method for mapping service identifiers to specific addresses within the CATS framework. It details extensions to DNS-SD to support CATS-specific service discovery requirements and describes how the discovery mechanism integrates with other components of the CATS architecture to enable compuating-aware traffic steering. |
| | AI Network for Training,Inference,and Agentic Interactions |
| |
|
Artificial Intelligence (AI) is rapidly transforming industries and everyday life, fueled by advances in model architectures, training paradigms, and data infrastructure for generation and consumption. Today, machine learning models are embedded in many of our daily activities, ranging from simple classification systems to advanced architectures such as large language models (LLMs) like ChatGPT, Claude, Grok, and DeepSeek. These models highlight the transformative potential of AI across diverse applications—from productivity tools to complex decision-making systems. However, the effectiveness and reliability of AI depend on two foundational processes: training and inference. Each process introduces unique challenges related to data management, computation, connectivity, privacy, trust, security, and governance. In this draft, we introduce the Data and Agent Aware-Inference and Training Network (DA-ITN)—a unified, intelligent, multi-plane network architecture designed to address the full spectrum of requirements needed to enable AI networks. DA-ITN provides a scalable and adaptive infrastructure that connects AI clients, data providers, model providers, agent providers, service facilitators, and computational resources to support end-to-end training, inference, and agentic interaction lifecycle operations. The architecture features dedicated control, data, and operations & management (OAM) planes to orchestrate training, inference, and agentic services while ensuring reliability, transparency, and accountability. By outlining the key requirements of such an AI ecosystem and demonstrating how DA-ITN fulfills them, this document presents an architecture for the future of AI-native networking—an "AI internet"—optimized for AI learning, efficient inference, scalable deployment, and seamless agent-to-agent collaboration. |
| | Multicast DNS-Based Service Discovery for Encrypted DNS Services |
| |
| | draft-liu-add-dnssd-edns-01.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Dongjie Liu, Zhiwei Yan, Guanggang Geng, Guoqiang Zeng |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks. It specifies new service types (_dot, _doh, _doq) and associated TXT record parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This extension addresses critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763. |
| | PPP IPCP Extensions for Encrypted DNS Server Negotiation |
| |
|
This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. These extensions allow PPP peers to exchange information about encrypted DNS servers supporting protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). The design maintains backward compatibility with RFC 1877 while addressing modern security requirements. |
| | Remote Procedure Call Identity Squashing via x.509 Certificate Fields |
| |
|
This document extends RPC-with-TLS, as described in [RFC9289], so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. |
| | SRv6 Policy Selector |
| |
|
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 a policy selection mechanism among the candidate SRv6 Policies based on network quality in IPv6 environments. |
| | Reservation of IPv6 Address Block 44::/16 for Amateur Radio Digital Communications (44Net) |
| |
|
This document proposes the reservation of the IPv6 address block 44::/16 for use by the global amateur radio community. The allocation would serve as the IPv6 successor to the legacy IPv4 network 44.0.0.0/8, historically known as AMPRNet or 44Net, which has provided a unified, non-commercial address space for amateur radio digital communications for more than four decades. The goal of this proposal is to maintain global cohesion and routing consistency for amateur radio networks as they transition to IPv6, while preserving the service's unique social and regulatory context. Amateur networks operate under national licensing frameworks and are limited to educational, experimental, and public-service purposes, distinguishing them from commercial Internet use. The proposed prefix would remain part of the global unicast routing table, enabling interoperability, research, and gateway connectivity between amateur systems and the wider Internet. This document outlines the historical rationale for an amateur radio IPv6 allocation, describes the technical and governance considerations for maintaining a contiguous and hierarchically managed address space, and specifies the IANA action required to reserve 44::/16 as a special-purpose global IPv6 prefix for amateur radio use. |
| | Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) |
| |
|
In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements. |
| | Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation |
| |
|
The Model Context Protocol (MCP) is an open standard that enables Large Language Model (LLM) applications to seamlessly integrate with external data sources and tools by exposing Resources, Prompts and Tools in a JSON-RPC 2.0 transport. This document describes a mapping of MCP roles, primitives and security model to the network management domain so that network devices act as MCP servers and network controllers act as MCP clients. This document also extends the model to Device-to-Device (D2D) collaboration, allowing network elements to perform distributed fault correlation when the controller is unreachable or when real-time cross-device data is required. The goal is to provide an intent-based, conversational and secure approach for automated network troubleshooting, configuration validation, and closed-loop remediation without inventing new protocols or device agents. |
| | MCP-based Network Measurement Framework: Using Model Context Protocol for Intelligent Network Measurement |
| |
|
This document proposes a framework for intelligent network measurement using the Model Context Protocol (MCP). By treating network devices as MCP servers, and treating network controllers, management systems, or network devices with LLM capability as MCP clients, this framework enables natural language-driven, AI-assisted network measurement operations. The framework leverages MCP's standardized communication protocol to provide real-time network performance monitoring, intelligent fault diagnosis, topology discovery, and automated measurement workflows. This document describes the architecture, use cases, and security considerations for implementing MCP-based network measurement systems. |
| | Scheduling Network Resources for Machine Learning Clusters |
| |
|
Large Language Models (LLMs) are pushing the boundaries of technology. The scale that they have reached currently vastly exceeds the capacity of any single compute unit (XPU); this requires a distributed approach where multiple XPUs are connected via a "backend" network, sometimes in a single data center, but increasingly in multiple data centers connected by a "data center interconnect" (DCI). We are approaching the point where the scale exceeds that of a single data center, thus requiring multiple such data centers connected via a "data center interconnect" network. Training and inferencing are expensive and critical operations, thus they are typically scheduled, i.e., the (compute) resources they need are carefully estimated, allocated and deployed so that these resources are efficiently used. However, while compute investment in these LLM processing clusters dwarfs that of networks, it is becoming increasingly clear that the latter can greatly impact the former. This has been the focus of recent conferences, including the fantel Birds of a Feather meeting in IETF 123, @Scale: Networking 2025 and Open Compute Project 2025. This memo proposes that the same care that is taken regarding allocation of compute resources to jobs be taken with networking resources: that they are estimated, allocated and deployed alongside compute resources; that they have contingency plans in case of network glitches; and that a holistic view be taken in order to optimize job completion times of training and inferencing jobs. |
| | Graph based Meta Schema for collaborative Operations |
| |
|
Graph based Meta Schema for collaborative Operation |
| | Export of Source Address Validation (SAV) Information in IPFIX |
| |
| | draft-cao-opsawg-ipfix-sav-01.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Qian Cao, Mingqing(Michael) Huang, Benoit Claise, Tianran Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to verify SAV effectiveness, audit rule correctness, and analyze source address spoofing events. |
| | IMAP OBJECTID Account Identifier extension |
| |
|
This document extends the IMAP OBJECTID extension (RFC 8474) to support account identifiers, enabling IMAP servers to provide account-level context for mailboxes when multiple accounts are accessible through a single IMAP connection. This extension is particularly relevant for environments where IMAP mailboxes include shared mailboxes from multiple JMAP accounts, as defined in the JSON Meta Application Protocol (JMAP). By introducing the ACCOUNTID object identifier, this specification ensures that mailboxes can be uniquely identified across different accounts in both IMAP and JMAP contexts, thereby facilitating seamless interoperability between the two protocols in multi-account scenarios. |
| | Secure Asset Transfer Protocol (SATP) Terminology |
| |
|
This memo collates existing terminology related to digital assets, asset networks and distributed ledger technology (DLT) that are relevant to the secure asset transfer protocol (SATP) and the IETF more broadly. Existing terms are borrowed as much as possible, and new terms are introduced only when necessary and with emphasis on technology neutrality. |
| | NTPv5 Timestamp Extension Field |
| |
|
This document describes an alternative timestamp to the Monotonic Receive Timestamp Extension Field defined in NTP version 5 (NTPv5) when transferring frequency offset. The new extension field, named Monotonic RAW Receive Timestamp Extension Field uses a stable clock source that is not affected by NTP adjustment. It provides more accurate frequency-transfer offset between a remote server and local client, which further enhances the accuracy of time synchronization. |
| | DNS Resource Records for the Data Interoperability Protocol |
| |
|
This document specifies a set of new DNS Resource Record (RR) types to support the Data Interoperability Protocol (DIP). DIP models entities as "Data Objects" (DOs) indexed by "Data Object Identifiers" (DOIs), which are syntactically equivalent to DNS domain names. The RR types specified herein-DLR, DOPK, DOAUTH, DODIGEST, DOCG, and DOALGO-are designed to hold key attributes of a DO. This approach addresses the inherent limitations of repurposing existing RR types (such as TXT) with respect to structured data representation, efficiency in handling binary data, and query granularity. The result is a native, efficient, and extensible mechanism for discovering and managing DO metadata via the DNS. |
| | Advertisement of Algorithm in BGP |
| |
|
This document proposes extensions to BGP to support algorithm-based end-to-end path establishment. |
| | Model Context Protocol (MCP) Extensions for Network Equipment Management |
| |
| | draft-zw-opsawg-mcp-network-mgmt-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Guanming Zeng, Jianwei Mao, Bing Liu, Xiaotong Shang, Qiangzhou Gao, Zhenbin Li, Qin WU |
| | Working Group: |
Individual Submissions (none) |
|
The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework for interaction between AI applications and external context sources. This document specifies minimal extensions that allow network equipment (routers, switches, etc.) to act as MCP servers while controllers act as MCP clients. New capability tokens, tools, resources, prompts, and error codes are defined without breaking existing MCP implementations. |
| | Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-Based Networking |
| |
| | draft-zeng-opsawg-llm-netconf-gap-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Guanming Zeng, Jianwei Mao, Bing Liu, Nan Geng, Xiaotong Shang, Qiangzhou Gao, Zhenbin Li |
| | Working Group: |
Individual Submissions (none) |
|
Large Language Models (LLMs) are entering network operations through natural-language intent interfaces. Existing south-bound protocols (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for conversational, semantically-rich, multi-agent orchestration. This document provides a systematic gap analysis and identifies extension points for each protocol to meet intent-based networking requirements. |
| | When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios |
| |
|
NETCONF provides robust configuration transactions and YANG-based data models, but falls short in scenarios requiring AI-driven semantic translation, long-lived cross-domain orchestration, multi- agent consensus, rapid DevOps iteration, or delivery of large non- configuration artifacts. This document systematically analyzes the functional gaps and presents Model Context Protocol (MCP) and Agent- to-Agent (A2A) as complementary solutions. Implementation guidance and coexistence models are also provided. |
| | Network AI Agent Use Cases and Requirements in 6G |
| |
|
This draft introduces use cases related to network AI agents in 6G, with a focus on the interaction workflows of network AI agents in two distinct scenarios: connectivity services and third-party application services. These use cases primarily draw upon 6G-related scenarios outlined in the 3GPP technical report [TR22.870]. Furthermore, the document elaborates on the integration of network AI agents within the 6G framework and discusses corresponding network requirements. |
| | Agent Networking Scenarios of Digital Banking |
| |
|
This document describes several typical digital banking scenarios, and discusses the trend of banking digitalization evolving to agentic service inteconnection. Then, this document proposes an agent networking architecture based on the core component which is agent gateway. |
| | Zero trust standards in IETF: use cases and problem statement |
| |
|
The traditional "castle-and-moat" security paradigm is no longer effective for some emerging scenarios, such as cloud services, remote workforces and intelligent agents. Zero trust (ZT) has emerged as the new paradigm, holding on the "never trust, always verify" principle, treats every single access request as untrudted and requires veficication. While a high-level atchitectural guidance exists, notably from NIST in SP 800-207 where thtenants of zero trust are well interperated, the industry lacks the open, interoperable framework and protocol necessary for building multi-vendor zero trust practice enrironment. This document presents the problem statement for zero trust interoperability, outlines the key use cases, and argue for the need for standardization in the IETF. It discusses the possible scope for zero trust standardization work in the IETF, identifying which aspects are well suited for the IETF protocols and which are better addressed by other bodies. The aim of this document is to initiate a discussion in the IETF community on the necessity and prospective of promoting zero trust related work here. |
| | Requiring Support for Appealing to the IESG and IAB |
| |
|
RFC2026 describes the procedure for appealing decisions or process failures to the IESG and the IAB. This document updates RFC2026 and requires that an appellant must first gain support for their appeal before an appeal may be considered by the body it is submitted to. |
| | The IETF Chair May Delegate |
| |
|
This document proposes that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates several existing RFCs to enable that. It also proposes a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. |
| | Encoding rules of YANG 'instance-identifier' in the Concise Binary Object Representation (CBOR) |
| |
|
Encoding rules of YANG-CBOR [RFC9254] are incomplete for 'instance- identifier' YANG data type. This document defines missing encoding rules for this data type. |
| | The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation |
| |
|
This document registers a Well-Known URI, /.well-known/awp.json, and a companion Link Relation Type, awp. The resource exposes a small, machine-readable description of common website workflows (states, actions, and resulting events) so automated agents can act predictably without scraping. The format is JSON and intentionally minimal. |
| | Use Cases and Requirements of Communication Protocol for Measurement Agents on Network Devices |
| |
|
This document focuses on the use cases and requirements of communication protocols for measurement agents on network devices. |
| | Use Cases and Requirements of Communication Protocol for Troubleshooting Agents on Network Devices |
| |
|
This document focuses on the use cases and requirements of communication protocols for troubleshooting agents on network devices. |
| | A Packet Marking Policy for Low Latency,Low Loss,and Scalable Throughput (L4S) |
| |
|
Low Latency, Low Loss, and Scalable Throughput (L4S)[RFC9330] is a technology designed to mitigate queueing delays while maintaining high throughput for IP traffic. In real-time communication (RTC) applications over 5G networks, rapidly fluctuating wireless link conditions impose strict requirements on congestion control algorithms, which must simultaneously ensure low latency and high bandwidth utilization. This document proposes a packet marking policy for L4S in 5G networks, where intermediate base station devices compute a link load factor and use it as a probabilistic signal to mark packets in L4S flows. |
| | AI Governance and Accountability Protocol (AIGA) |
| |
|
This document specifies the AI Governance and Accountability (AIGA) Protocol version 1.0, a practical, economically viable, and technically enforceable framework for governing autonomous AI agents. AIGA 1.0 is designed to address real-world deployment constraints, adversarial agent scenarios, and economic incentive alignment. The protocol is founded on a Tiered Risk-Based Governance model, applying proportional oversight to agents based on their capabilities. All agents are governed by an Immutable Kernel Architecture which provides a non-modifiable Trusted Computing Base (TCB) for enforcing policy. This is combined with Action-Based Authorization, where critical operations require real-time approval. To solve the single-point-of-failure problem, the protocol uses a Federated Authority Network of regional, cross-validating hubs and provides a Network-Level Quarantine Protocol for enforcement. The entire framework is designed around Economic Incentive Alignment, making compliance the most economically rational choice for operators. For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced, redundant mechanisms including Multi-Vendor TEE Attestation (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB) Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and Double Ratchet Cryptography. |
| | Secure Asset Exchange Protocol |
| |
|
This document describes the Secure Asset Exchange (SAE) Protocol. SAE is an extension of the Secure Asset Transfer (SAT) Protocol that enables the asset exchange interoperability mode. It specifies the required modifications necessary to the SAT message flows to facilitate asset exchange between asset networks. Gateways that support the SAT protocol can be extended to also support SAE, enabling support for both asset transfer and asset exchange in a single set of gateways. |
| | Export of Path Segment Identifier Information in IPFIX |
| |
|
This document introduces new IPFIX Information Elements to identify the Path Segment Identifier(PSID)s for SR-MPLS and SRv6 paths identification. |
| | 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. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-12.txt |
| | Date: |
02/11/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. |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-16.txt |
| | Date: |
02/11/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 System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token Specification to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. This draft updates RFC7643 defining additional attributes for "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema and updates RFC7644 with optional new Asynchronous SCIM Request capability. |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces |
| |
| | draft-ietf-teas-yang-te-40.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. |
| | NAT64 WKP |
| |
|
This document removes the requirement in Section 3.1 of RFC6052 that the NAT64 Well-Known Prefix 64:FF9B::/96 MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. |
| | Workload Identifier |
| |
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |
| | Workload Authentication Using Mutual TLS |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). |