Index - Month Index of IDs
All IDs - sorted by date)
| Protocol-Specific Profiles for JSContact | ||||||||||||||
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate. | |||||||||||||
| Simple Mail Transfer Protocol | ||||||||||||||
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. | |||||||||||||
| Group Key Management using IKEv2 | ||||||||||||||
|
This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. | |||||||||||||
| 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. | |||||||||||||
| DKIM Access Control and Differential Changes | ||||||||||||||
|
This document specifies a DKIM (RFC 6376) extension that allows cryptographic verification of SMTP (RFC 5321) envelope data, and of DKIM signatures prior to IMF (RFC 5322) message content changes along the message path, addressing thus security glitches, and offering a new world of email solutions that move complexity away from lower network layers, where problems cannot be solved, complying with David Wheeler's fundamental theorem of software engineering, that "We can solve any problem by introducing an extra level of indirection". It updates DKIM to obsolete certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. It is the future of email for email of the future. | |||||||||||||
| OAuth 2.0 App2App Browser-less Flow | ||||||||||||||
|
This document describes a protocol allowing a _Client App_ to obtain an OAuth grant from a _Native App_ using the [App2App] pattern, providing *native* app navigation user-experience (no web browser required), despite both apps residing on different trust domains. | |||||||||||||
| A Comprehensive Errata for 'retransmission-allowed' XML Element | ||||||||||||||
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. | |||||||||||||
| SCHC Minimal Architecture | ||||||||||||||
|
This document investigates the requirements of a minimal architecture for the Static Context Header Compression (and fragmentation) protocol (SCHC). The intent is to identify the essential components their relationships and interfaces. To do so, the document considers scenarios of increasing complexity involving the use of SCHC, from a simple point-to-point communication to a more complex deployment involving multiple SCHC Instances communicating with each other. In this process, the authors hope to identify the essential components of a SCHC architecture and their relationships. | |||||||||||||
| 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. | |||||||||||||
| Export of terminal and application identification Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document specifies the extended information elements used in IPFIX (IP Flow Information Export) to export application layer information for identifying terminal and cloud application related information. | |||||||||||||
| RFC Editor Model (Version 3) | ||||||||||||||
|
This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280. This document updates RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and 8729. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/ (https://datatracker.ietf.org/edwg/rswg/documents/). There is a repository for this draft at https://github.com/ paulehoffman/9280-updates (https://github.com/ paulehoffman/9280-updates). | |||||||||||||
| Secure Asset Transfer (SAT) Interoperability Architecture | ||||||||||||||
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. | |||||||||||||
| Secure Asset Transfer (SAT) Use Cases | ||||||||||||||
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. | |||||||||||||
| Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes | ||||||||||||||
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with transitive attributes signaling Validation State may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators SHOULD ensure Validation States are not signaled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into BGP Communities. | |||||||||||||
| Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | ||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. | |||||||||||||
| Members | ||||||||||||||
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates RFC9085 to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates RFC9085 and RFC9086 to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. | |||||||||||||
| Mutually Authenticating TLS in the context of Federations | ||||||||||||||
|
This informational independent submission to the RFC series describes a means to use TLS 1.3 to perform machine-to-machine mutual authentication within federations. This memo is not a standard. It does not modify the TLS protocol in any way, nor does it require changes to common TLS libraries. TLS is specified and standardized by the IETF's TLS working group. The framework enables interoperable trust management for federated machine-to-machine communication. It introduces a centrally managed trust anchor and a controlled metadata publication process, ensuring that only authorized members are identifiable within the federation. These mechanisms support unambiguous entity identification and reduce the risk of impersonation, promoting secure and policy-aligned interaction across organizational boundaries. | |||||||||||||
| Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that aims to prevent some kinds of downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. | |||||||||||||
| Time Synchronization over QUIC | ||||||||||||||
|
This document proposes a modern, secure, and extensible time synchronization protocol designed to operate over the QUIC transport protocol. Known as TSQ (Time Synchronization over QUIC), this protocol aims to address the limitations of traditional NTP by leveraging QUIC's encryption, widespread UDP/443 acceptance, and multiplexed stream capabilities. TSQ is designed for contemporary deployment environments, including enterprise networks, cloud-native systems, containers, and mobile devices, where traditional UDP-based NTP struggles with security, scalability, or operational reliability. | |||||||||||||
| Open Ethics Transparency Protocol | ||||||||||||||
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. | |||||||||||||
| The "_for-sale" Underscored and Globally Scoped DNS Node Name | ||||||||||||||
|
This document defines an operational convention for using the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. This approach offers the advantage of easy deployment without affecting ongoing operations. As such, the method can be applied to a domain name that is still in full use. | |||||||||||||
| Identification,Sequence Number and Payload Option for IPv6 NDP and IPv4 ARP Ping | ||||||||||||||
|
IPv6 Neighbor Discovery Protocol (NDP) and IPv4 Address Resolution Protocol (ARP) can be used to perform "ping" tests that overcome nodes' refusal to respond to IPv6 and IPv4 ICMP Echo Requests. A drawback is that NDP and ARP do not carry an Identification, Sequence Number and Payload for these ping tests. This memo proposes an IPv6 Neighbor Discovery Option that adds these fields to the NDP and ARP packets used to perform ping tests. | |||||||||||||
| Selective Disclosure for Agent Discovery and Identity Management (SD- Agent) | ||||||||||||||
|
This document defines how Selective Disclosure for JWTs (SD-JWT) integrates with Agent-to-Agent (A2A) systems to provide privacy- preserving agent discovery and cryptographically verifiable identity management. It specifies the SD-Card format - an SD-JWT encoding of Agent Cards that enables selective disclosure of agent capabilities, contact information, and operational metadata while maintaining cryptographic integrity and preventing correlation across different interaction contexts. | |||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance | ||||||||||||||
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. | |||||||||||||
| TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key | ||||||||||||||
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC. | |||||||||||||
| An Application Layer Interface for Non-IP device control (NIPC) | ||||||||||||||
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices, as well as a CBOR-based publish-subscribe interface for streaming data. The described interfaces are extensible. The specification also defines a protocol mapping function to to map this interface to commonly used non-IP protocols. | |||||||||||||
| BGP Usage for SD-WAN Overlay Networks | ||||||||||||||
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. | |||||||||||||
| A YANG Data Model for Transport Network Client Signals | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. | |||||||||||||
| An Algorithm for Computing Dynamic Flooding Topologies | ||||||||||||||
|
Link-state routing protocols suffer from excessive flooding in dense network topologies. Dynamic flooding [I-D.ietf-lsr-dynamic-flooding] alleviates the problem by decoupling the flooding topology from the physical topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the physical topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used as a flooding topology in dynamic flooding. This document discloses the algorithm that we have developed in order to make it easier for other developers to implement similar algorithms. We do not claim that our algorithm is optimal, rather it is a pragmatic effort and we expect that further research and refinement can improve the results. We are not proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work, however we have no objections if the working group chooses to do so. | |||||||||||||
| Merkle Tree Certificates | ||||||||||||||
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. | |||||||||||||
| Global Token Revocation | ||||||||||||||
|
Global Token Revocation enables parties such as a security incident management tool or an external Identity Provider to send a request to an Authorization Server to indicate that it should revoke all of a user's existing tokens and require that the user re-authenticates before issuing new tokens. | |||||||||||||
| 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. | |||||||||||||
| IKEv2 Support of ML-DSA | ||||||||||||||
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. NIST has recently standardized ML-DSA, which is a signature algorithm believed to be secure against Quantum Computers. This document describes how to use ML-DSA with IKEv2 as an authentication scheme. | |||||||||||||
| RTP Payload Format for Avatar | ||||||||||||||
|
This memo outlines RTP payload formats for the MPEG-I Avatar data. A Avatar Stream format (ASF) is composed of Avatar animation unit (AAU) including a AAU header and zero or more AAU packets. The RTP Payload header format allows for packetization of a AAU unit in an RTP packet payload as well as fragmentation of a AAU into multiple RTP packets. | |||||||||||||
| Balance Mapping for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for retrieving the client balance and other financial information. | |||||||||||||
| Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness | ||||||||||||||
|
This document standardizes usage of Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) as identifiers to enable trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems (UAS) in Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). DETs can serve as Session IDs for privacy, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. | |||||||||||||
| Transaction Tokens | ||||||||||||||
|
Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external programmatic requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures. | |||||||||||||
| Source Address Validation in Inter-domain Networks Gap Analysis,Problem Statement,and Requirements | ||||||||||||||
|
This document provides a gap analysis of existing inter-domain source address validation mechanisms, describes the problem space, and defines the requirements for technical improvements. | |||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things | ||||||||||||||
|
The Semantic Definition Format (SDF) is concerned with Things, namely physical objects that are available for interaction over a network. SDF is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. | |||||||||||||
| The Locator/ID Separation Protocol (LISP) for Multicast Environments | ||||||||||||||
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. | |||||||||||||
| 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. | |||||||||||||
| MTU propagation over EVPN Overlays | ||||||||||||||
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. | |||||||||||||
| All PEs as DF | ||||||||||||||
|
The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. | |||||||||||||
| Secure IP Binding Synchronization via BGP EVPN | ||||||||||||||
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. | |||||||||||||
| Lightweight Directory Access Protocol (LDAP): Additional Syntaxes | ||||||||||||||
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes. | |||||||||||||
| Evidence Package Format Specification | ||||||||||||||
|
Taking evidence is a key part of any software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. | |||||||||||||
| Mutually Authenticating TLS in the context of Federations | ||||||||||||||
|
This informational independent submission to the RFC series describes a means to use TLS 1.3 to perform machine-to-machine mutual authentication within federations. This memo is not a standard. It does not modify the TLS protocol in any way, nor does it require changes to common TLS libraries. TLS is specified and standardized by the IETF's TLS working group. The framework enables interoperable trust management for federated machine-to-machine communication. It introduces a centrally managed trust anchor and a controlled metadata publication process, ensuring that only authorized members are identifiable within the federation. These mechanisms support unambiguous entity identification and reduce the risk of impersonation, promoting secure and policy-aligned interaction across organizational boundaries. | |||||||||||||
| 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. | |||||||||||||
| Reliable and Available Wireless Architecture | ||||||||||||||
|
Reliable and Available Wireless (RAW) extends the reliability and availability of DetNet to networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet Service sub-layer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. | |||||||||||||
| DKIM2 - signing the source and destination of every email | ||||||||||||||
|
This memo provides a rationale for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. | |||||||||||||
| 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. | |||||||||||||
| PCEP Procedures and Extension for VLAN-based Traffic Forwarding | ||||||||||||||
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key procedures of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. | |||||||||||||
| RFC Style Guide | ||||||||||||||
|
This document describes the fundamental and unique style conventions currently in use for the RFC Series. It captures the RFC Production Center's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide". Note: This draft is being developed and discussed in the GitHub repo | |||||||||||||
| SDP Offer/Answer for RTP over QUIC (RoQ) | ||||||||||||||
|
This document is intended to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. The document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/ Answer can be used to set up an RTP connection using QUIC. This document also contains non-normative guidance for implementers. | |||||||||||||
| Providing DNSSD Service on Infrastructure | ||||||||||||||
|
DNS Service Discovery provides several mechanisms whereby hosts can discover and advertise services on an IP network. Such discovery can be done using Multicast DNS (mDNS) or DNS, and advertising can be done with DNSSD Service Registration Protocol (SRP) or mDNS. This document describes a way to provide a unified DNSSD proxy service that allows hosts to advertise services using SRP and discover services using unicast DNS via a Discovery Proxy rather than using of mDNS, in scenarios where mDNS is currently the only option. | |||||||||||||
| Testing Applications' IPv6 Support | ||||||||||||||
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-Stack (IPv4+IPv6), and IPv6-only scenarios, including "true IPv6-only" scenarios. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. | |||||||||||||
| Sub-Link Scoped IPv6 Multicast Addressing | ||||||||||||||
|
The IPv6 addressing architecture for multicast has the scope of a multicast group embedded in its address, with the smallest non- reserved scopes being interface-local and link-local, numbered 1 and 2. This document suggests the introduction of a scope inbetween these two, for use with lower-layer transport multicast that reaches parts of a link. Since there is no room to insert a scope value for this, a separate address block is used. A mapping for Ethernet as lower-layer transport is provided. | |||||||||||||
| Taxonomy of Composite Attesters | ||||||||||||||
|
This document further refines different kinds of RFC 9334 Composite Attesters. | |||||||||||||
| Considerations for Performing Safe Measurement on the Internet | ||||||||||||||
|
Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the Internet, it can present risks to user privacy. This document describes briefly those risks. It also outlines considerations for researchers to reference when designing internet measurements to ensuring that those measurements can be carried out with user safety as a priority. | |||||||||||||
| Device Schema Extensions to the SCIM model | ||||||||||||||
|
The initial core schema for SCIM (System for Cross-domain Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. | |||||||||||||
| 464XLAT Customer-side Translator (CLAT): Node Recommendations | ||||||||||||||
|
464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates Requirements for IPv6 Customer Edge Routers to Support IPv4-as- a-Service (RFC8585) by providing recommendations for the node developers on enabling and disabling CLAT functions. | |||||||||||||
| BGP Based Multicast | ||||||||||||||
|
This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multicast trees. | |||||||||||||
| BIER Ping and Trace | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast-related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. | |||||||||||||
| DNS over CoAP (DoC) | ||||||||||||||
|
This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). | |||||||||||||
| CCNx Content Object Chunking | ||||||||||||||
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. | |||||||||||||
| Extensible In-band Processing (EIP) Architecture and Framework | ||||||||||||||
|
Extensible In-band Processing (EIP) extends the functionality of the IPv6 protocol considering the needs of future Internet services / 6G networks. This document discusses the architecture and framework of EIP. Two separate documents respectively analyze a number of use cases for EIP and provide the protocol specifications of EIP. | |||||||||||||
| IPv6-to-IPv6 Network Prefix Translation | ||||||||||||||
|
This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document obsoletes RFC 6296. | |||||||||||||
| Deterministic Networking specific MNA | ||||||||||||||
|
In IETF, the Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. This document focuses on the MPLS Data Plane, namely, how to use MNA (MPLS Network Action) for DetNet flows, when forwarded over an MPLS technology-based network domain. | |||||||||||||
| Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) ) | ||||||||||||||
|
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based authentication of DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. | |||||||||||||
| Clarifying SRv6 SID List Processing | ||||||||||||||
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. Segments are indicated by Segment Identifiers (SIDs). SRv6 utilizes the Segment Routing Header (SRH), an IPv6 extension header, that includes a SID list indicating the sequence of segments and any additional processing to be performed. This document updates RFC 8754 by clarifying the processing of SID list entries. It does not change any elements of the SRv6 architecture. | |||||||||||||
| 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. | |||||||||||||
| Path Computation Element Communication Protocol for Source Address Validation | ||||||||||||||
|
This document presents a method of Path Computation Element (PCE) for Source Address Validation (SAV) in networks. It extends Path Computation Element Communication Protocol (PCEP) to support SAV policy distribution and synchronization between PCEP speakers for threat mitigation for source address spoofing. | |||||||||||||
| CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL) | ||||||||||||||
|
This document proposes Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ). CHEQ allows humans to confirm decisions and actions proposed by AI Agents prior to those decisions being acted upon. It also allows humans to provide information required for tool invocation, without disclosing that information to the AI agent, protecting their privacy. CHEQ aims to guarantee that AI Agent hallucinations cannot result in unwanted actions by the human on whose behalf they are made. CHEQ can be integrated into protocols like the Model Context Protocol (MCP) and the Agent-to- Agent (A2A) protocols. It makes use of a signed object which can be carried in those protocols. | |||||||||||||
| Secure ICMPv6 Messages for Network Segment Characterization | ||||||||||||||
|
This document proposes a new ICMPv6 message type, ICMPv6-SEC, designed to convey cryptographically verifiable information using COSE objects and CBOR-encoded certificates. The purpose is to signal segment-specific network characteristics, including high RTT, congestion, policy constraints, and traffic treatment expectations. These messages can describe either the segment beyond the current hop (forward segment) or the local segment on which the source resides. Certificates may be embedded or referenced via DNS using cryptographic hashes. The mechanism is optimized for high-speed environments by allowing the use of static, signed descriptors for destination prefixes. | |||||||||||||
| Agent Context Protocol | ||||||||||||||
|
This specification defines a standard message and protocol for communicating Agent Context information between AI agents. | |||||||||||||
| Next Generation browser | ||||||||||||||
|
Next Generation browser | |||||||||||||
| IETF/IRTF Educational Processes | ||||||||||||||
|
This document describes the basic use cases for the IETF to have a series of activities specifically tailored for educational and outreach purposes. These uses cases cover areas such as academia, industry, policy makers or anyone interested in learning the necessary skillset required to easily integrate into the innerworking of the IETF. | |||||||||||||
| SRv6 Anycast VPN Service | ||||||||||||||
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines anycast flavor for SRv6 Service SIDs carried in BGP messages. | |||||||||||||
| EAT Attestation Results | ||||||||||||||
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. | |||||||||||||
| SRv6 Path Egress Protection | ||||||||||||||
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. | |||||||||||||
| Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568. | |||||||||||||
| Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service | ||||||||||||||
|
For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an multi-domain IPv6-only environment(i.e.,IPv4-as- a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, examines the utilization of SRv6, and discusses the security considerations. | |||||||||||||
| OSPFv3 Extensions for BIER | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. The BIER architecture uses MPLS or other encapsulations to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. | |||||||||||||
| JSContact Version 2.0: A JSON Representation of Contact Data | ||||||||||||||
|
This document defines version "2.0" of JSContact. It defines the "uid" property of a Card object to be optional, rather than mandatory as defined in previous version "1.0". Other than changing the "uid" property, all other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional "uid" property from and to vCard. | |||||||||||||
| IMAP OBJECTID Partial Implementation extention | ||||||||||||||
|
This document extends the IMAP OBJECTID specification in RFC8474 describes persistent identifiers for Mailboxes, Emails, and Threads in email. Some servers may be unable to provide persistent identifiers for one of these but be able to provide data for others, so this extension allows a server to specify that it can provide some reliable ids without needing to implement all data types. | |||||||||||||
| 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. | |||||||||||||
| Integration of Speech Codec Enhancement Methods into the Opus Codec | ||||||||||||||
|
This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] | |||||||||||||
| Augmented-by Addition to the YANG Library | ||||||||||||||
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Zephyre777/draft-lincla-netconf-yang-library- augmentation. | |||||||||||||
| NETCONF Transport Port Numbers | ||||||||||||||
|
This document releases NETCONF-related port number IANA assignments that have not stood the test of time (e.g., assignments for Historic NETCONF-related protocols or for a transport not used by a given NETCONF-related protocol). | |||||||||||||
| Metadata Query Protocol | ||||||||||||||
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. | |||||||||||||
| SAML Profile for the Metadata Query Protocol | ||||||||||||||
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.24. | |||||||||||||
| Composite Token Claims | ||||||||||||||
|
Composition claims are CBOR Web Token claims that define logical relationships between sets of claims. | |||||||||||||
| HTTP Streaming: Standard for Age-Appropriate Video Content Guidelines (VCG) and Delivery | ||||||||||||||
|
The delivery of inappropriate video content for OTT and Social Media with HTTP video streaming is a serious worldwide problem. Most of the countries have established age-related and parental guidelines to warn about inappropriate or unintended content, particularly for children. However, these guidelines do not offer the freedom or convenience for audiences to avoid consumption of inappropriate content for their target age group instead just provide warning messages only.The Age-Relevant Video Content Guidelines (VCG) Standard defines a standard meta data format which covers fully and partially scene by scene age relevancy meta data for video and audio content and hence establishes a mechanism for delivering video and audio content tailored to the viewers' age groups. The Video Content Guidelines(VCG) is a meta data file which can enable existing HTTP based adaptive streaming standard like HLS, DASH, CMAF, MSS and HDS with updating manifest file using VCG meta data, that ensures only the target age-appropriate content is delivered to the audience and in-appropriate data can be skipped or modified so that different age group audience can choose what they want to watch. This ensures the compatibility of with the standard adaptive streaming protocols and players, so that the existing social Media and OTT streaming infrastructure continue to work without any major changes. | |||||||||||||
| A YANG Module for Entitlement Inventory | ||||||||||||||
|
This document proposes a YANG module for incorporating entitlements in a network inventory. Entitlements define the rights for their holder to use specific capabilities in a network element(s). The model is rooted by the concept of the capabilities offered by a network element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. | |||||||||||||
| Using IEEE Std 802.1AB (LLDP) for IETF LSVR neighbor discovery and configuration | ||||||||||||||
|
IEEE Std 802.1AB, known as the Link Layer Discovery Protocol (LLDP), can be applied to LSVR neighbor discovery and configuration. This can be achieved by using a "nearest router group address" as the LLDP Scope MAC Address to target LSVR interfaces while advertising a set of LSVR-specific LLDP TLVs. These LSVR-specific TLVs are defined using LLDP Organizationally Specific TLVs, as specified by LLDP for use by individual organizations to allow them to define their own Type-Length-Value (TLV) objects for exchange over the LLDP protocol. The IETF Organizationally Specific TLVs for LSVR can be encoded using the IETF IANA OUI (RFC 9542). This document provides an overview of applying LLDP to LSVR neighbor discovery and configuration and specifies the IETF Organizationally Specific TLVs that support link discovery for LSVR routers. In addition, a brief discussion of the use of IEEE Connectivity Fault Management (CFM) as specified in IEEE Std 802.1Q-2022 cl 18-22 for link liveliness is included. | |||||||||||||
| Considerations for Protective DNS Server Operators | ||||||||||||||
|
Protective DNS is a defense mechanism deployed on recursive resolvers to prevent users from accessing malicious domains. For domain names in the blocklist, it rewrites DNS resolution responses to point to secure destinations (e.g., safe servers) to prevent users from accessing malicious entities. Owing to its effective defenses against common cyber attack behaviors—such as command-and-control (C2) communications of malware—Protective DNS deployment has surged via various initiatives. Not only have renowned DNS service providers adopted this defense, but some countries have also launched national-scale deployments. Meanwhile, studies analyzing Protective DNS have identified implementation diversity. Thus, this document aims to provide specific operational and security considerations for Protective DNS. It is intended primarily for entities seeking to deploy Protective DNS for defensive purposes, offering deployment and security considerations. | |||||||||||||
| ICMPv6 Prefix Redirect Messages | ||||||||||||||
|
The existing IPv6 ICMPv6 Redirect Message informs a host of a better next hop for a single destination IPv6 address. There are use cases for informing a host of a better next hop for a prefix or range of IPv6 addresses that includes or covers the single destination address that triggered the ICMPv6 redirect message. This memo specifies an ICMPv6 Prefix Redirect Message for this purpose. | |||||||||||||
| QMux | ||||||||||||||
|
This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. 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. | |||||||||||||
| SRv6 L3VPN Fast Reroute | ||||||||||||||
|
In some multihoming SRv6 L3VPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR behaviors for L3 SRv6 Service SIDs in BGP messages. | |||||||||||||
| Making RFC and Internet-Draft Boilerplate Less Conspicuous | ||||||||||||||
|
This document establishes a new policy for RFCs and Internet-Drafts that moves all the fluff (copyright notices and that sort of thing) to the bottom of documents. | |||||||||||||
| Short Paths in CoAP | ||||||||||||||
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus registering (relatively verbose) well-known URI paths. This document introduces an option that allows expressing well-known paths in as little as two bytes. | |||||||||||||
| Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks | ||||||||||||||
|
This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. | |||||||||||||
| Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) | ||||||||||||||
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay in the OAM transit and decapsulating nodes. | |||||||||||||
| Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305 | ||||||||||||||
|
This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. | |||||||||||||
| Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography | ||||||||||||||
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. | |||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime | ||||||||||||||
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). | |||||||||||||
| TCP-AO Protection for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. | |||||||||||||
| HTTP Unencoded Digest | ||||||||||||||
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. | |||||||||||||
| BGP UPDATE for SD-WAN Edge Discovery | ||||||||||||||
|
The document describes the BGP mechanisms for SD-WAN (Software Defined Wide Area Network) edge node attribute discovery. These mechanisms include a new tunnel type and sub-TLVs for the BGP Tunnel- Encapsulation Attribute [RFC9012] and set of NLRI (network layer reachability information) for SD-WAN underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turn propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. | |||||||||||||
| A Base YANG Data Model for Network Inventory | ||||||||||||||
|
This document defines a base YANG data model for network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. | |||||||||||||
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) | ||||||||||||||
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. | |||||||||||||
| LISP Geo-Coordinates | ||||||||||||||
|
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo- Coordinate. This document updates RFC8060. | |||||||||||||
| WARP Streaming Format | ||||||||||||||
|
This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. | |||||||||||||
| Authentication scheme for MOQT using Common Access Tokens | ||||||||||||||
|
A token-based authentication scheme for use with Media Over QUIC Transport. | |||||||||||||
| SATP Network Identification | ||||||||||||||
|
There is currently a lack of a standard network identification or numbering for digital asset networks. This deficiency makes it difficult for the transfer of digital assets from one network to another, due among others, to the possibility in the collision in the numbering of the remote networks. This document proposes a globally unique 32-byte identifier for each asset network based on some unique inherent characteristics of each network. | |||||||||||||
| IETF Experiments | ||||||||||||||
|
This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. | |||||||||||||
| OAuth Client ID Metadata Document | ||||||||||||||
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. | |||||||||||||
| QUIC bandwidth awareness Acknowledgements | ||||||||||||||
|
This document defines a quic ACK frame format for notifying path available bandwidth. | |||||||||||||
| Media over QUIC - Use Cases | ||||||||||||||
|
MoQ is designed to serve live tracks over a CDN to viewers with varying latency and quality targets: the entire spectrum between real-time and VOD. However, it's difficult to understand how to use the transport given the layering and complexity of live media delivery. This document outlines how an application could use MoQ to deliver video, audio, and metadata in a variety of scenarios. | |||||||||||||
| Post-Quantum Enhancements to EAP-TLS and EAP-TTLS | ||||||||||||||
|
This document proposes enhancements to the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS) and EAP Tunneled TLS (EAP-TTLS) to incorporate post-quantum cryptographic mechanisms. It also addresses challenges related to large certificate sizes and long certificate chains, as identified in RFC9191, and provides recommendations for integrating PQC algorithms into EAP-TLS and EAP- TTLS deployments. | |||||||||||||
| AI Network for Training,Inference,and Agentic Interactions | ||||||||||||||
|
Artificial Intelligence (AI) is rapidly reshaping industries and daily life, driven by advances in large language models (LLMs) such as ChatGPT, Claude, Grok, and DeepSeek. These models have demonstrated the transformative potential of AI across diverse applications, from productivity tools to complex decision-making systems. However, the effectiveness and reliability of AI hinge on two foundational processes: training and inference. Each presents unique challenges related to data management, computation, connectivity, privacy, trust, security, and governance. This document introduces the Data Aware-Inference and Training Network (DA-ITN)—a unified, intelligent, multi-plane network architecture designed to address the full spectrum of AI system requirements. DA- ITN provides a scalable and adaptive infrastructure that connects AI clients, data providers, service facilitators, and computational resources to support end-to-end AI lifecycle operations. The architecture features dedicated control, data, and operations & management (OAM) planes to orchestrate training and inference while ensuring reliability, transparency, and accountability. By outlining the key requirements of AI systems and demonstrating how DA-ITN fulfills them, this document presents a vision for the future of AI- native networking—an "AI internet"—optimized for continuous learning, scalable deployment, and seamless agent-to-agent collaboration. | |||||||||||||
| Requirements for Paid Web Crawling | ||||||||||||||
|
This document suggests requirements (and non-requirements) for paid Web crawling protocols. | |||||||||||||
| 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. | |||||||||||||
| IS-IS,OSPF and BGP-LS Traffic Engineering and Flexible Algorithm Extensions for Utilizing Bit Error Rate Metrics | ||||||||||||||
|
This document describes extensions to IS-IS, OSPF, and BGP-LS Traffic Engineering to distribute the Bit Error Rate (BER) and Packet Error Rate (PER) metrics for the links that can be used for flexible algorithm and path selection purpose. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. | |||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Utilizing Bit Error Rate (BER) Metrics | ||||||||||||||
|
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF IS-IS, and BGP-LS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to utilize Bit Error Rate (BER) and Packet Error Rate (PER) as constraints for end-to-end path computation. | |||||||||||||
| Media over QUIC - Lite | ||||||||||||||
|
moq-lite is designed to fanout live content from publishers to any number of subscribers across the internet. Liveliness is achieved by using QUIC to prioritize the most important content, potentially starving or dropping other content, to avoid head-of-line blocking while respecting encoding dependencies. While designed for media, it is an agnostic transport, allowing relays and CDNs to forward content without knowledge of codecs, containers, or encryption keys. | |||||||||||||
| Network infrastructure Hiding Protocol | ||||||||||||||
|
The Network infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to implement Zero Trust principles by rendering protected network resources invisible to unauthorized entities. By requiring authentication before connection and operating at OSI layers 5 , NHP conceals IP addresses, ports, and domains from exposure to reconnaissance and automated exploitation, effectively reducing the attack surface. This draft defines the architecture, message format, and workflow of the NHP protocol, outlines its security objectives, and provides guidance for integration into modern network infrastructures and Zero Trust deployments. | |||||||||||||
| Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) | ||||||||||||||
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. | |||||||||||||
| Multicast DNS-Based Service Discovery for Encrypted DNS Services | ||||||||||||||
|
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. | |||||||||||||
| OAuth 2.0 Resource Parameter in Access Token Response | ||||||||||||||
|
This specification defines a new parameter, resource, to be returned in OAuth 2.0 access token responses. It enables clients to confirm the intended protected resource (resource server) for the issued token. This mitigates ambiguity and certain classes of security vulnerabilities such as resource mix-up attacks, particularly in systems that use the Resource Indicators for OAuth 2.0 specification [RFC8707]. | |||||||||||||
| 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. | |||||||||||||
| Cross-Device Flows: Security Best Current Practice | ||||||||||||||
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. | |||||||||||||
| Updates to Audience Values for OAuth 2.0 Authorization Servers | ||||||||||||||
|
This specification updates the requirements for audience values for tokens whose audience is an OAuth 2.0 authorization server to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. | |||||||||||||
| Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document introduces extensions in three main areas. Mechanisms for informing PCEP peers about the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects. This document updates RFC 8664 and RFC 9603 to allow such extension. The document specifies SR-Algorithm constraint, enabling refined path computations that can leverage IGP algorithm logic, including Flexible Algorithms, and their associated constraints and optimization metrics. It defines new metric types for the METRIC object required to support SR-Algorithm based path computation, but also applicable to Label Switched Paths (LSPs) setup using different Path Setup Types. | |||||||||||||
| Secure Reporting of Update Status | ||||||||||||||
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. | |||||||||||||
| Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domain | ||||||||||||||
|
A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format for use in deployments with multiple trust domains. | |||||||||||||
| Cryptographic Algorithms for Internet of Things (IoT) Devices | ||||||||||||||
|
The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019). | |||||||||||||
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors | ||||||||||||||
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. | |||||||||||||
| ML-KEM Post-Quantum Key Agreement for TLS 1.3 | ||||||||||||||
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement. | |||||||||||||
| Generic Address Assignment Option for 6LoWPAN Neighbor Discovery | ||||||||||||||
|
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. | |||||||||||||
| A Vocabulary For Expressing AI Usage Preferences | ||||||||||||||
|
This document proposes a standardized vocabulary for expressing preferences related to how digital assets are used by automated processing systems. This vocabulary allows for the creation of structured declarations about restrictions or permissions for use of digital assets by such systems. | |||||||||||||
| Associating AI Usage Preferences With Content | ||||||||||||||
|
Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines how preferences can be signaled as part of the acquisition of content in HTTP. This document updates RFC 9309 to allow for the inclusion of usage preferences. | |||||||||||||
| JSCalendar: A JSON Representation of Calendar Data | ||||||||||||||
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. | |||||||||||||
| iCalendar Format Extensions for JSCalendar | ||||||||||||||
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). | |||||||||||||
| Media Type Registration for Protocol Buffers | ||||||||||||||
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. | |||||||||||||
| Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) | ||||||||||||||
|
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024, as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. This document updates RFC 3535 as the report of the follow-up IAB workshop on Network Management. | |||||||||||||
| BGP SR Policy Extensions for metric | ||||||||||||||
|
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. | |||||||||||||
| PROBE: A Utility for Probing Interfaces | ||||||||||||||
|
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. | |||||||||||||
| Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. | |||||||||||||
| PACC - Automatic configuration for mail servers,calendar and contacts sync | ||||||||||||||
|
Set up a mail account with only email address and password. This uses the DNS SRV mechanism to find the configuration. It is meant for new mail servers that adapt their configuration to current best practices. | |||||||||||||
| The Messaging Layer Security (MLS) Extensions | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. | |||||||||||||
| YANG Module Versioning Requirements | ||||||||||||||
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. | |||||||||||||
| Extension to BGP's Route Refresh Message | ||||||||||||||
|
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests. | |||||||||||||
| Destination-IP-Origin-AS Filter for BGP Flow Specification | ||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. | |||||||||||||
| BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches | ||||||||||||||
|
MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. | |||||||||||||
| Multicast VPN Upstream Designated Forwarder Selection | ||||||||||||||
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. | |||||||||||||
| 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. 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/wcsmith/draft-quic-receive-ts. | |||||||||||||
| BGP SR Policy Extensions for template | ||||||||||||||
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. | |||||||||||||
| Simplified MVPN for BIER and IR | ||||||||||||||
|
Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution. | |||||||||||||
| Signaling MNA Capability Using IGP and BGP-LS | ||||||||||||||
|
This document defines a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS). | |||||||||||||
| NTS extensions for enabling pools | ||||||||||||||
|
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. | |||||||||||||
| ASPA-based AS_PATH Verification for BGP Export | ||||||||||||||
|
This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers, check for local misconfigurations and detect ASPA registration errors, thus avoiding the advertisement of invalid routes. | |||||||||||||
| RADIUS attributes for National Security and Emergency Preparedness Service | ||||||||||||||
|
This document describes RADIUS attributes for supporting authorization of Emergency Preparedness Communication Service (EPCS), enabling authorized users to benefit from preferential access to Wi- Fi network resources during congestion. | |||||||||||||
| Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI. | |||||||||||||
| Proposal for experimentation with stateless IPv6 multicast source routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing Headers (MRH) | ||||||||||||||
|
This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/ SRv6 networks as well as BIER networks as a related effort. | |||||||||||||
| Instance Information for SDF | ||||||||||||||
|
This document discusses types of Instance Information to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf) and will ultimately define Representation Formats for them as well as ways to use SDF Models to describe them. // The present revision –05 is intended as input for IETF 123, with a // few observations from the Hackathon addressed and this status // paragraph updated. | |||||||||||||
| The HiAE Authenticated Encryption Algorithm | ||||||||||||||
|
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. | |||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Verified Contact Information | ||||||||||||||
|
This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. | |||||||||||||
| SRv6 for Deterministic Path Placement in AI Backends | ||||||||||||||
|
This document describes the use of SRv6 to enable deterministic path placement in AI backends, optimizing load balancing and congestion control for predictable GPU workloads. | |||||||||||||
| BGP-4 Path Attribute Filtering Capability | ||||||||||||||
|
Path Attributes in the BGP-4 protocol (RFC 4271) carry data associated with BGP routes. Many of the Path Attributes carried in BGP are intended for limited scope deployment. However, the extension mechanism defined by BGP that carries these attributes often carries them farther than necessary, sometimes with unfortunate results. This document defines a mechanism using BGP Capabilities (RFC 5492) that permits eBGP speakers to determine what Path Attributes should be permitted to cross external BGP routing boundaries. | |||||||||||||
| The IPv6 Multicast Routing Headers (MRH) | ||||||||||||||
|
This document describes the IPv6 extensions to support an experiment in which new IPv6 Routing headers that support stateless replication are implemented and deployed for IPv6 Segment Routing Networks. Collectively, these headers are called Multicast Routing Header (MRH). One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment. | |||||||||||||
| Simplified Language for Specifying Interoperability | ||||||||||||||
|
The key words used to establish interoperability requirements, can be reduced to a single key word, "MUST". All others are either redundant or cover for latent interoperability issues and can be discouraged. | |||||||||||||
| vCon Lifecycle Management using SCITT | ||||||||||||||
|
This document proposes using the SCITT (Supply Chain, Integrity, Transparency, and Trust) protocol to record, communicate and coordinate the lifecycle of Virtual Conversations (vCons), which are standardized containers for conversational data like call recordings, transcripts, and chat logs. While vCons enable capturing and sharing conversation details for AI analysis and business purposes, they lack mechanisms for proving compliance with privacy regulations and consent management. SCITT addresses this by providing an immutable, append-only transparency ledger that records key lifecycle events—from vCon creation and consent management to call recording, as well as data processing and deletion—enabling entities to demonstrate regulatory compliance and maintain trust across distributed systems. The framework specifically addresses consent management challenges under regulations like GDPR and CCPA, where consent can be revoked at any time, requiring coordinated deletion across all parties that have received the vCon. By combining vCons with SCITT, organizations can build scalable, transparent governance systems that protect personal data rights while enabling responsible use of conversational data for AI and business applications. | |||||||||||||
| The DNS Stamps Specification | ||||||||||||||
|
This document specifies DNS Stamps, a compact format that encodes the information needed to connect to DNS resolvers. DNS Stamps encode all necessary parameters including addresses, hostnames, cryptographic keys, and protocol-specific configuration into a single string using a standard URI format. The specification supports multiple secure DNS protocols including DNSCrypt, DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), and Oblivious DoH. | |||||||||||||
| Voice Conversation (vCon) Consent Attachment | ||||||||||||||
|
This document defines a consent attachment type for Voice Conversations (vCon), establishing standardized mechanisms for recording, verifying, and managing consent information within conversation containers as defined in the vCon core specification. The consent attachment addresses privacy compliance challenges through structured metadata including consenting parties, temporal validity periods, and cryptographic proof mechanisms. The specification defines the mandatory and optional fields for consent attachments, including expiration timestamps, party references, dialog segments, and consent arrays. It supports granular consent management through purpose-based permissions and integrates with the AI Preferences vocabulary for automated processing systems. The attachment type incorporates SCITT (Supply Chain Integrity, Transparency, and Trust) for cryptographic transparency and provides integration patterns for consent ledger services. Key features include automated consent detection during conversation processing, auditable consent records with cryptographic proofs, support for consent revocation through superseding statements, and integration with existing privacy regulations. The consent attachment enables organizations to maintain compliance while providing sufficient structure for automated processing and verification of consent throughout the vCon lifecycle. | |||||||||||||
| Probabilistic Reveal Tokens | ||||||||||||||
|
Fraud detection often relies on high-entropy signals that can also be used to track users across sites. Probabilistic Reveal Tokens (PRTs) attempt to balance the needs of fraud detection and tracking prevention by sampling at a rate that is too low for scaled cross- site tracking, but sufficient for fraud detection in aggregate scenarios. This document describes the PRT protocol, which allows browsers to reveal sensitive signals (e.g., IP address) on a per-site basis with provable probability p_reveal, while websites can use PRTs to measure traffic quality and update denylists. | |||||||||||||
| Deploying and Using Email in Deep Space | ||||||||||||||
|
This document is an assessment on the email protocols to be used in deep space and provides recommendations to deploy and use email in deep space. | |||||||||||||
| A Data Manifest for Contextualized Telemetry Data | ||||||||||||||
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the data manifest, composed of two YANG data models (the platform manifest and the non-normative data collection manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The data manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. | |||||||||||||
| Attestation Event Stream Subscription | ||||||||||||||
|
This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). In RATS, the Conceptional Messages defined can potentially be subscribed to. Specifically, the YANG module defined in this document augments the YANG module for TPM-based Challenge-Response based Remote Attestation (CHARRA) to allow for subscription to the Conceptual Message type Evidence. Additionally, this document provides the methods and means to define additional Event Streams for other Conceptual Messages than Evidence as illustrated in the RATS Architecture, e.g., Attestation Results, Reference Values, or Endorsements. The module defined requires at least one TPM 1.2, TPM 2.0, or equivalent hardware implementation providing the same protected capabilities as TPMs to be available in the Attester the YANG server is running on. | |||||||||||||
| System for Cross-domain Identity Management: Definitions,Overview,Concepts,and Requirements | ||||||||||||||
|
This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. | |||||||||||||
| Resource Public Key Infrastructure (RPKI) Manifest Number Handling | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that an issuer intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which an issuer must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. bounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document updates RFC9286 by specifying issuer and RP behaviour for this scenario. | |||||||||||||
| SSH Strict KEX extension | ||||||||||||||
|
This document describes a small set of modifications to the Secure Shell (SSH) protocol to fix the so-called Terrapin Attack on the initial key exchange. | |||||||||||||
| YANG Data Models for Network Resource Partitions (NRPs) | ||||||||||||||
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. | |||||||||||||
| IETF Network Slice Topology YANG Data Model | ||||||||||||||
|
An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. | |||||||||||||
| Hybrid key exchange in TLS 1.3 | ||||||||||||||
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. | |||||||||||||
| The Transport Layer Security (TLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. | |||||||||||||
| IANA Registry Updates for TLS and DTLS | ||||||||||||||
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. | |||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | ||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. | |||||||||||||
| Privacy Primer for vCon Developers | ||||||||||||||
|
This document serves as a primer for technical professionals involved in the processing (which includes collecting, using, disclosure, and erasure) of personal data, including not only basic identifiers like name, age, and address, but also sensitive data contained in communications, including biometrics obtained from audio and video recordings. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, sharing, access, retention, and disclosure of individuals’ data. The document covers fundamental privacy principles, defines important roles in data processing, and explains individuals’ rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address individuals' data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices. | |||||||||||||
| The vCon - Conversation Data Container - Overview | ||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | |||||||||||||
| BRSKI discovery and variations | ||||||||||||||
|
This document specifies how to make BRSKI communications autoconfiguring, extensible and resilient in the face of simultaneous use of different variations of the BRSKI protocol (BRSKI, BRSKI-AE, BRSKI-PRM, constrained BRSKI, stateless constrained BRSKI proxies). This document specifies a data model, IANA registry and BRSKI component procedures to achieve this. This document does not define any new discovery methods. Instead, its data model allows to signal all current (and future) variations of the BRSKI family of protocols consistently via different existing network discovery mechanisms: DNS-SD, CoAP discovery (CORE-LF) and GRASP. Additional/future discovery mechanisms can also be supported through the IANA registry. Automatic resiliency and load-sharing are enabled through the use of discovery mechanisms and the provisioning of multiple instances of BRSKI components such as registrars and Join Proxies. This document specifies the procedures to support load-sharing and (fast) failover under failure and recovery of redundant components. Future proof deployments of BRSKI requires Join Proxies that automatically support any current and future BRSKI variation. This document specifies the procedures how Join Proxies can support this through specific Join Proxy protocol behavior and the use of discovery mechanisms. The specification for discovery of pledges by their IDevID as introduced by BRSKI-PRM is refined in this document. | |||||||||||||
| Constrained GeneRic Autonomic Signaling Protocol | ||||||||||||||
|
This document proposes the Constrained GeneRic Autonomic Signaling Protocol (cGRASP), a constrained and lightweight variant of the GeneRic Autonomic Signaling Protocol (GRASP, or the standard GRASP). cGRASP reduces message overhead and replaces TCP with CoAP as the transport protocol. By leveraging CoAP's reliability features and deployment maturity, cGRASP can provide reliable signaling services without relying on TCP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential approaches to adapting the cGRASP to work on the network without IP connectivity. | |||||||||||||
| Cumulative DMZ Link Bandwidth and load-balancing | ||||||||||||||
|
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor-level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers. | |||||||||||||
| Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a traditional cryptographic component and a post-quantum (PQ) KEM. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. | |||||||||||||
| Identifier Update for OSCORE | ||||||||||||||
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. | |||||||||||||
| 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. | |||||||||||||
| BGP Next Hop Dependent Characteristics Attribute | ||||||||||||||
|
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. This specification also 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. | |||||||||||||
| The Multicast Application Port | ||||||||||||||
|
This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. | |||||||||||||
| MPLS Network Action (MNA) Sub-Stack Solution | ||||||||||||||
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. This solution document specifies In-stack network action and In-stack data specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". | |||||||||||||
| IPv4+ The Extended Protocol Based On IPv4 | ||||||||||||||
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. | |||||||||||||
| Notable CBOR Tags | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. | |||||||||||||
| Application of the Alternate Marking Method to the Segment Routing Header | ||||||||||||||
|
This document describes an alternative experimental approach for the application of the Alternate-Marking Method to SRv6. It uses an experimental TLV in the Segment Routing Header, and thus participation in this experiment should be between coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343 and the scope of the experiment is to determine whether those are significant and attractive to the community. This protocol extension has been developed outside the IETF as an alternative to the IETF’s standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. Researchers are invited to submit their evaluations of this work to the RFC Editor for consideration as independent submissions or to the IETF SPRING working group as Internet-Drafts. | |||||||||||||
| Layer-3 Accessible EVPN Services | ||||||||||||||
|
This draft describes layer-3 accessible EVPN service interfaces, which aim is to connect the layer 2 customers to one EVPN backbone, via the layer 3 network, and keep the traffic isolation among different layer 2 customers. It proposes to extend the VxLAN packet format to transfer the customer's Virtual Network Identifier(VNI) information, and also the related control plane extension. | |||||||||||||
| Semantic Definition Format (SDF): Mapping files | ||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation. | |||||||||||||
| LISP for Satellite Networks | ||||||||||||||
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. | |||||||||||||
| Terminal Identity Authentication Based on Address Label | ||||||||||||||
|
This document proposes an IPv6-based address label terminal identity authentication architecture, which tightly binds identity information to the source address of data packets. This approach enables hop-by- hop identity authentication while ensuring source address verification. The mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document details the implementation of address label authentication within the IPv6 extension header. | |||||||||||||
| Benchmarking Methodology for 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. | |||||||||||||
| Secure SMTP/TLS SRV Announcement | ||||||||||||||
|
This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. | |||||||||||||
| Open Cloud Mesh | ||||||||||||||
|
Open Cloud Mesh is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. | |||||||||||||
| Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF | ||||||||||||||
|
This draft proposes a new intra-domain Source Address Validation (SAV) solution. This solution leverages the Bidirectional Metric- based Shortest Path First (BM-SPF) mechanism to avoid the complexity introduced by asymmetric routing for source address validation. It allows intra-domain routers to generate directly the SAV rule from the router's FIB table, based on the reality that the source and destination interface will be same if the IGP domain is symmetric assured. | |||||||||||||
| Eligibility Concept in Segment Routing Policies | ||||||||||||||
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. | |||||||||||||
| Concise Selector for Endorsements and Reference Values | ||||||||||||||
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. | |||||||||||||
| TCP Extended Options | ||||||||||||||
|
The TCP header can accommodates 40 octets of TCP options. However, modern applications may require more than 40 octets of TCP Options. Therefore, this document describes an experiment that extends the TCP Options field. If this experiment is successful, it will demonstrate that the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility. | |||||||||||||
| A Rich Authorization Request Framework for Groupware Services using OAuth 2.0 | ||||||||||||||
|
The OAuth 2.0 authorization framework is widely used to provide clients with delegated access to user data. However, the core specification leaves the definition of access scopes to individual service providers. This has led to a fragmented ecosystem for common groupware services (Mail, Calendaring, Contacts), where each provider uses proprietary, non-interoperable scope identifiers. Client applications, such as desktop mail clients, are forced to hardcode configurations for a small number of large providers, stifling innovation and harming open ecosystems. This document proposes a framework that combines a minimal set of standardized OAuth 2.0 scopes with a detailed structure for use with OAuth 2.0 Rich Authorization Requests (RAR). This hybrid approach provides a simple baseline for legacy clients while enabling powerful, granular, and privacy-preserving authorization for modern clients. It defines RAR type values, actions, datatypes, and custom fields for specifying fine-grained permissions for groupware resources. | |||||||||||||
| Rights Contributors Provide to IETF Intellectual Property Management Corporation | ||||||||||||||
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This document updates [RFC5378] to change the name of the IETF Trust to the IETF IPMC and the editor's contact info, but does not change the policies or intellectual property rights in Contributions to the IETF from those in [RFC5378]. | |||||||||||||
| Authoritative DNS Server-Side Answer Generation | ||||||||||||||
|
The traditional model for DNS is that authoritative servers would read DNS data from static zone files and use that to answer DNS queries. Modern DNS servers do not act in this way, and their answers are created dynamically - either periodically or at query time. This document presents a taxonomy breaking down the most common and useful methods used to customize responses on the authortiative side, as well as a survey of implementations by current large authoritative operators. | |||||||||||||
| Guidance for migration to Post-Quantum Cryptography | ||||||||||||||
|
This document provides guidance on migration to post-quantum cryptography (PQC) in internet protocols. It outlines the challenges and considerations that protocol designers and implementers should take into account when transitioning from traditional cryptographic algorithms to PQC algorithms, which are designed to be secure against quantum computer attacks. It is intended for cryptographic protocol designers within the IETF community, as well as technology developers and implementers responsible for deploying PQC standards. | |||||||||||||
| Applicability & Manageability of SCONE signal for a mobile network | ||||||||||||||
|
This document identifies applicability of SCONE signal in a mobile network and outlines operational considerations, or manageability of SCONE signal in the operator network. Importantly, this document also describes 3GPP network elements that are capable of rate- limiting a UDP 4-tuple to communicate an upper bound on achievable bitrate termed "throughput advice" to implement SCONE protocol. | |||||||||||||
| 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 wants 802.11 Flexible Multicast Service | ||||||||||||||
|
IEEE 802.11 Flexible Multicast Service (FMS) addresses reliability issues in IPv6 due to aggressive powersave optimizations in 802.11 client devices. The intent of this document is to collect consensus in the IETF 6man (IPv6 Maintenance) working group to request either/both the IEEE 802.11 Working Group and/or the Wifi Alliance's certification process to make implementing FMS a requirement. | |||||||||||||
| Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent Collaboration | ||||||||||||||
|
This draft defines a new agent collaboration protocol, named the Internet of Agents Protocol (IoA Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to emerging 6G application scenarios such as intelligent transportation, smart healthcare, and large-scale human–AI teaming. | |||||||||||||
| 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). | |||||||||||||
| 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. | |||||||||||||
| A Survey of the Current State of CLAT Availability and Performance on Non-Mobile Systems | ||||||||||||||
|
This document reports findings in the availability and operational performance of the client side translator (CLAT) feature within 464XLAT as defined in [RFC6877]. It also identifies remaining issues in providing ubiquitous and efficient CLAT support on a global scale. Since publication in April 2013, 464XLAT has made a significant impact on mobile networks wishing to implement endpoints purely with IPv6. This has allowed the IPv6 Internet to expand dramatically as well as increase IPv6 deployments across wireline and enterprise- style networks. | |||||||||||||
| OpenPGP Key Replacement | ||||||||||||||
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. | |||||||||||||
| (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS | ||||||||||||||
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. | |||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). | |||||||||||||
| A YANG Data Model for ARP | ||||||||||||||
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. | |||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | ||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | |||||||||||||
| Segment Routing IPv6 Security Considerations | ||||||||||||||
|
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. | |||||||||||||
| IP in Deep Space: Key Characteristics,Use Cases and Requirements | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on the Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. | |||||||||||||
| Generic Fault-Avoidance Routing Protocol for Data Center Networks | ||||||||||||||
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. | |||||||||||||
| A Decent LISP Mapping System (LISP-Decent) | ||||||||||||||
|
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. | |||||||||||||
| 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. | |||||||||||||
| IPsec problems when used in NTN network | ||||||||||||||
|
This document describes the problems in the use of IPsec in satellite Internet and NTN network scenarios. | |||||||||||||
| A YANG Module for SRv6 Next-Hop RIB Extensions | ||||||||||||||
|
This document defines a YANG data module for configuring and managing SRv6 next hop information for Routing, which augments the YANG data model for Routing Management (RFC8349). | |||||||||||||
| Bitstream Transport over Ethernet (BToE) | ||||||||||||||
|
This document defines Bitstream Transport over Ethernet (BToE), a method for capturing and transporting raw Layer 1 bitstream data across Ethernet Layer 2 networks. Unlike traditional frame-based transport mechanisms, BToE enables fully transparent transmission of physical layer signals, allowing for cable fault isolation, ASIC/FPGA debugging, and transceiver validation by preserving the integrity of all bits, including those outside valid Ethernet frames. | |||||||||||||
| Enhanced Bailiwick Checking for DNS Resolvers to Mitigate Cache Poisoning Vulnerabilities | ||||||||||||||
|
The Domain Name System (DNS) relies on caching to function efficiently. However, DNS cache poisoning remains a significant threat. The "bailiwick" rule is a fundamental security mechanism intended to prevent resolvers from caching out-of-bailiwick data sent by malicious or misconfigured authoritative servers. Current DNS standards provide high-level guidance on bailiwick checking but lack specific algorithmic definitions, leading to inconsistent implementations across different DNS software. These inconsistencies can be exploited, particularly in DNS servers that operate in multiple modes, such as Conditional DNS Servers (CDNS), which may act as both recursive resolvers and forwarders and often share a common cache. This document specifies enhanced and more precise rules for bailiwick checking in DNS resolvers, including those operating as forwarders or CDNS. The goal is to provide clearer guidelines for implementers, reduce the attack surface for cache poisoning, and improve the overall security and robustness of the DNS infrastructure. The recommendations herein are informed by recent research highlighting vulnerabilities in existing bailiwick implementations. | |||||||||||||
| Clarifying DNS Resolver Behavior for the Recursion Desired (RD) Flag | ||||||||||||||
|
This document addresses inconsistencies observed in the handling of the Recursion Desired (RD) flag in DNS queries by various DNS resolver implementations, particularly when the RD flag is cleared (set to 0). Such inconsistencies have been shown to be exploitable, leading to potent Denial of Service (DoS) amplification attacks. This document provides clear guidance and recommendations for DNS resolver (including forwarding and recursive resolvers) behavior when processing queries with different RD flag settings. The goal is to enhance DNS security, mitigate specific amplification attack vectors, and ensure more predictable and robust DNS operations. | |||||||||||||
| Best Current Practices for DNS Resolver Resilience Against Coordinated Amplification Attacks | ||||||||||||||
|
This document describes an attack vector, exemplified by the "DNSBomb" attack, that leverages the emergent behavior of several widely- implemented DNS resolver mechanisms. By combining query timeouts, query aggregation, and response timing, an attacker can turn a set of resolvers into powerful amplifiers for a Pulsing Denial-of-Service (PDoS) attack. This attack is difficult to detect due to its low average traffic rate but can be highly effective at overwhelming a target's resources. This document provides operational guidance and a set of best practices for DNS resolver implementers and operators to mitigate this threat. The goal is to harden the DNS ecosystem by reducing the potential for resolvers to be used in such a coordinated fashion, thereby improving the operational resilience of the DNS. | |||||||||||||
| DNS Response Pre-processing Security Guidelines: Awaiting Valid Responses | ||||||||||||||
|
The security and robustness of the Domain Name System (DNS) significantly depend on how resolvers handle received responses. Current DNS specifications lack exhaustive and consistent guidance on response pre-processing, particularly for malformed or unexpected packets. This specification gap has led to implementation divergences and has been shown to introduce security vulnerabilities such as DNS cache poisoning, Denial of Service (DoS), and resource exhaustion, as detailed in the TUDOOR attack research. This document aims to clarify and standardize the behavior of DNS resolvers when receiving and initially processing responses from upstream servers. The core proposal is the "Awaiting Valid Responses" mechanism, which mandates that a resolver, after issuing a query, MUST maintain a defined waiting period to receive a well- formed, relevant, and validated response. During this period, non- compliant incoming packets should be discarded, and the resolver should continue to wait until a valid response is received or the query times out. This document provides guidance for DNS implementers to mitigate security risks arising from flaws in response pre-processing logic. | |||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for SR Policy Performance Metric | ||||||||||||||
|
This document describes a way to report the performance metrics for Traffic Engineering (TE) Policy by the Path Computation Element Communication Protocol(PCEP). | |||||||||||||
| Requirements and Enabling Technologies of Agent Protocols for 6G Networks | ||||||||||||||
|
Agent application will be surely the common trend for a long time in future, while agent protocols are so popular that more and more protocols are being worked out. The telecommunication industry plays a pivotal role in the Agent ecosystem. The overall technology success hinges on how telecommunication industry could adopt the latest AI trends in order to handle its specific usage scenarios and performance requirements, e.g., in the coming 6G era. This document will provide the first attempt to analyze the agent protocol requirements and relevant enabling technologies based on mobile communication system specific characteristics. | |||||||||||||
| A Profile for Mapping Origin Authorizations (MOAs) | ||||||||||||||
|
This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object, it provides a means that the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. When receiving the MOA objects from the relying partie, PE device can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. | |||||||||||||
| Structured Email | ||||||||||||||
|
This document specifies how a machine-readable version of the content of email messages can be added to those messages. | |||||||||||||
| Cursor-based Pagination of SCIM Resources | ||||||||||||||
|
This document updates RFC7643 and RFC7644 by defining additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM service providers that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. | |||||||||||||
| Return Routability Check for DTLS 1.2 and DTLS 1.3 | ||||||||||||||
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Implementations offering the CID functionality described in RFC 9146 and RFC 9147 are encouraged to also provide the return routability check functionality described in this document. For this reason, this document updates RFC 9146 and RFC 9147. | |||||||||||||
| Terminal Access Controller Access-Control System Plus over TLS 1.3 (TACACS+ over TLS) | ||||||||||||||
|
This document specifies the use of Transport Layer Security (TLS) version 1.3 to secure the communication channel between a Terminal Access Controller Access-Control System Plus (TACACS+) client and server. TACACS+ is a protocol used for Authentication, Authorization, and Accounting (AAA) in networked environments. The original TACACS+ protocol, does not mandate the use of encryption or secure transport. This specification defines a profile for using TLS 1.3 with TACACS+, including guidance on authentication, connection establishment, and operational considerations. The goal is to enhance the confidentiality, integrity, and authenticity of TACACS+ traffic, aligning the protocol with modern security best practices. This document updates RFC 8907. | |||||||||||||
| The JSON format for vCon - Conversation Data Container | ||||||||||||||
|
vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. | |||||||||||||
| The JSON vCon - Contact Center Extension | ||||||||||||||
|
A vCon is container for data and information relating to a human conversation. This document defines an extension for the JSON vCon schema in support of call, support or contact center application of the vCon conversational data exchange format. | |||||||||||||
| The vCon - Conversation Data Container - Overview | ||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | |||||||||||||
| Carrying Network Resource (NR) related Information in IPv6 Extension Header | ||||||||||||||
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. | |||||||||||||
| IPv6 Node Requirements | ||||||||||||||
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. | |||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. | |||||||||||||
| Protecting EST Payloads with OSCORE | ||||||||||||||
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. | |||||||||||||
| Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. | |||||||||||||
| Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (4) It extends the error handling at the AS, for which it defines a new error code. (5) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (6) It amends two of the requirements on profiles of the framework. | |||||||||||||
| Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. | |||||||||||||
| Per multicast flow Designated Forwarder Election for EVPN | ||||||||||||||
|
This document defines an enhancement to the Designated Forwarder (DF) election process in Ethernet Virtual Private Network (EVPN) environments. While traditional DF election operates at a per Virtual Local Area Network (VLAN) or per group of VLANs (in case of VLAN bundle or VLAN-aware bundle service) level, such granularity may not be sufficient for applications requiring optimized or isolated multicast forwarding. This specification introduces a refined DF election mechanism that extends existing hash-based methods to operate at a more granular level specifically at the tuple of Ethernet Segment Identifier (ESI), VLAN, and multicast flow. This approach enables improved traffic distribution, enhanced load balancing, and greater deployment flexibility for multicast delivery in EVPN based networks. The proposed method is designed to remain compatible with existing DF election procedures while offering targeted improvements for multicast scenarios. | |||||||||||||
| 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 describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. | |||||||||||||
| AC-Aware Bundling Service Interface in EVPN | ||||||||||||||
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. | |||||||||||||
| Weighted HRW and its applications | ||||||||||||||
|
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. | |||||||||||||
| Multiple Loss Ratio Search | ||||||||||||||
|
This document specifies extensions to "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) throughput search 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. | |||||||||||||
| Task Extensions to iCalendar | ||||||||||||||
|
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has seen limited adoption and use, mainly for personal reminders and to-do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. | |||||||||||||
| A Framework for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes. | |||||||||||||
| CATS Metrics Definition | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from the computing domain used for CATS. | |||||||||||||
| Packed CBOR | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -16 is intended as input to IETF 123, to address the // discussion about the use of simple values as reference items // during the 2025-06-11 CBOR interim meeting. It contains a number // of editorial improvements as well as the new concept of an // integration tag; it is for discussion whether the latter should or // should not be added to Packed CBOR. The wording of the present // revision continues to make use of the tunables A/B/C to be set to // specific numbers before completing the Packed CBOR specification; // not all the examples may fully align yet. | |||||||||||||
| CBOR Extended Diagnostic Notation (EDN) | ||||||||||||||
|
This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -18 // corrects a few omissions from -17; it is not intended to make // technical changes from -17. It is intended for use as an input // document for the CBOR WG meeting at IETF 123. | |||||||||||||
| CBOR Common Deterministic Encoding (CDE) | ||||||||||||||
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document documents the Best Current Practice for CBOR Common Deterministic Encoding (CDE), which can be shared by a large set of applications with potentially diverging detailed requirements. It also defines the term "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. | |||||||||||||
| A YANG data model to manage configurable DWDM optical interfaces | ||||||||||||||
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) [ITU-T_G.698.2] or any other ITU-T recommendation. Use cases are described in [RFC7698]. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of DWDM interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | |||||||||||||
| A YANG Data Model for Optical Impairment-aware Topology | ||||||||||||||
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for a Wavelength Switched Optical Network (WSON), while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for a Spectrum Switched Optical Network (SSON). This document provides a YANG data model for the impairment-aware TE topology in optical networks. | |||||||||||||
| Conveying Transceiver-Related Information within RSVP-TE Signaling | ||||||||||||||
|
The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. | |||||||||||||
| BBR Congestion Control | ||||||||||||||
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. | |||||||||||||
| Increase of the Congestion Window when the Sender Is Rate-Limited | ||||||||||||||
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. | |||||||||||||
| CDNI Logging Extensions | ||||||||||||||
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. | |||||||||||||
| Content Delivery Network Interconnection (CDNI) Named Footprints | ||||||||||||||
|
The document specifies an object-based semantics to CDNI footprint advertisement, that enables RESTful implementations of the FCI protocol. This approach enables multiple CDNI capabilities within the FCI to share common footprint definitions and allows footprint advertisement to be used in additional CDNI interfaces. This document further specifies operational enhancements to the CDNI footprint support. The document specifies an alternative, object-based approach to CDNI footprint advertisement, that enables RESTful implementations of the FCI protocol. This approach enables multiple CDNI capabilities within the FCI to share common footprint definitions and allows footprint advertisement to be used in additional CDNI interfaces. This document further specifies operational enhancements to the CDNI footprint support. | |||||||||||||
| The BBS Signature Scheme | ||||||||||||||
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. | |||||||||||||
| Guidelines for Writing Cryptography Specifications | ||||||||||||||
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. | |||||||||||||
| 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. | |||||||||||||
| Constrained Resource Identifiers | ||||||||||||||
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –23 attempts to address the AD review comments; // it is submitted right before the I-D deadline in order to serve as // discussion input to IETF 123 even though not all discussions have // completed. In particular, the updated handling of zone // identifiers requires some additional scrutiny. | |||||||||||||
| Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. | |||||||||||||
| Key Update for OSCORE (KUDOS) | ||||||||||||||
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. | |||||||||||||
| CoAP Transport Indication | ||||||||||||||
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. | |||||||||||||
| Key Usage Limits for OSCORE | ||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. | |||||||||||||
| Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) | ||||||||||||||
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. | |||||||||||||
| ML-DSA for JOSE and COSE | ||||||||||||||
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. | |||||||||||||
| Dataplane Enhancement Taxonomy | ||||||||||||||
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. | |||||||||||||
| Domain Control Validation using DNS | ||||||||||||||
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. | |||||||||||||
| DNS Multiple QTYPEs | ||||||||||||||
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). | |||||||||||||
| Extensible Authentication Protocol (EAP) Using Privacy Pass Token | ||||||||||||||
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. | |||||||||||||
| BMP v4: TLV Support for BGP Monitoring Protocol (BMP) Route Monitoring and Peer Down Messages | ||||||||||||||
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types. | |||||||||||||
| AS Path Prepending | ||||||||||||||
|
Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet. | |||||||||||||
| Byte Range PATCH | ||||||||||||||
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, facilitating random access writes and segmented uploads of resources. | |||||||||||||
| The HTTP Wrap Up Capsule | ||||||||||||||
|
HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. | |||||||||||||
| Guidelines for Writing an IANA Considerations Section in RFCs | ||||||||||||||
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. | |||||||||||||
| 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. | |||||||||||||
| 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 the standardization work for constrained-node networks. | |||||||||||||
| Responsiveness under Working Conditions | ||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. | |||||||||||||
| Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. | |||||||||||||
| ESP Header Compression with Diet-ESP | ||||||||||||||
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. | |||||||||||||
| The Role of the Internet Research Task Force (IRTF) | ||||||||||||||
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This document is a product of the Internet Research Steering Group (IRSG). | |||||||||||||
| A YANG Data Model for Network Inventory Location | ||||||||||||||
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. | |||||||||||||
| JMAP File Storage extension | ||||||||||||||
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. | |||||||||||||
| 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 protected 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. | |||||||||||||
| Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) | ||||||||||||||
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. | |||||||||||||
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | ||||||||||||||
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. | |||||||||||||
| Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). | |||||||||||||
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, In order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. | |||||||||||||
| EDHOC Authenticated with Pre-Shared Keys (PSK) | ||||||||||||||
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. | |||||||||||||
| Remote attestation over EDHOC | ||||||||||||||
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. | |||||||||||||
| Use of Remote Attestation with Certification Signing Requests | ||||||||||||||
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence and Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. | |||||||||||||
| Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) | ||||||||||||||
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) | |||||||||||||
| Composite ML-DSA for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. | |||||||||||||
| Unsigned X.509 Certificates | ||||||||||||||
|
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. | |||||||||||||
| A Mechanism for X.509 Certificate Discovery | ||||||||||||||
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether to fetch the Secondary Certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of Primary Certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. | |||||||||||||
| Clarification to processing Key Usage values during CRL validation | ||||||||||||||
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. | |||||||||||||
| LISP YANG Model | ||||||||||||||
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. | |||||||||||||
| LISP Canonical Address Format (LCAF) | ||||||||||||||
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. | |||||||||||||
| Interoperable Email Addresses for SMTPUTF8 | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding elements that harm human-to-human interoperation. This is one of a pair of documents: this contains recommendations for what addresses humans should use, such that address provisioning systems can restrain themselves to addresses that email valdidators accept. (This set can also be described in other ways, including "simple to cut-and-paste" and "understandable by some community".) Its companion defines simpler rules, accepts more addresses, and is intended for software like MTAs. | |||||||||||||
| SMTPUTF8 address syntax | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: This is simple to implement, contains only globally viable rules and is intended to be usable for software such an MTA. Its companion defines has more complex rules, takes regional usage into account and aims to allow only addresses that are readable and cut-and-pastable in some community. | |||||||||||||
| QUIC-Aware Proxying Using HTTP | ||||||||||||||
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. | |||||||||||||
| DNS Configuration for Proxying IP in HTTP | ||||||||||||||
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. | |||||||||||||
| YANG Data Model for Automatic Multicast Tunneling | ||||||||||||||
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. | |||||||||||||
| More Instant Messaging Interoperability (MIMI) message content | ||||||||||||||
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. | |||||||||||||
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS | ||||||||||||||
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. | |||||||||||||
| Deep Audio Redundancy (DRED) Extension for the Opus Codec | ||||||||||||||
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. | |||||||||||||
| Network Overlay Impacts to Streaming Video | ||||||||||||||
|
This document examines the operational impacts to streaming video applications caused by changes to network policies by network overlays. The network policy changes include IP address assignment, transport protocols, routing, and DNS resolvers, which in turn affect a variety of important content delivery aspects such as latency, CDN cache selection, delivery path choices, traffic classification and content access controls. | |||||||||||||
| Media over QUIC Transport | ||||||||||||||
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. | |||||||||||||
| Low Overhead Media Container | ||||||||||||||
|
This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the WARP streaming specification, which defines a catalog format for publishers to annouce and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. | |||||||||||||
| YANG Data Model for MPLS mLDP | ||||||||||||||
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| YANG Packages | ||||||||||||||
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. | |||||||||||||
| An Architecture for YANG-Push to Message Broker Integration | ||||||||||||||
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. | |||||||||||||
| SIMAP: Concept,Requirements,and Use Cases | ||||||||||||||
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. | |||||||||||||
| DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) | ||||||||||||||
|
DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. | |||||||||||||
| Trusted Path Routing | ||||||||||||||
|
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. | |||||||||||||
| Encoding Network Slice Identification for SRv6 | ||||||||||||||
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. | |||||||||||||
| Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP | ||||||||||||||
|
This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. | |||||||||||||
| Updated Rules for PCE Communication Protocol (PCEP) Object Ordering | ||||||||||||||
|
The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these messages are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. | |||||||||||||
| Additional addresses for QUIC | ||||||||||||||
|
This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. | |||||||||||||
| Template-Driven HTTP Request Proxying | ||||||||||||||
|
HTTP request proxying behaviors have long been part of the core HTTP specification. However, the core request proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative proxy service configuration for HTTP requests. The proxy service is identified by a URI Template, similarly to "connect-tcp" and "connect-udp". | |||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | ||||||||||||||
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. | |||||||||||||
| NTRU Key Encapsulation | ||||||||||||||
|
This draft document provides recommendations for the implementation of a post-quantum Key Encapsulation Mechanism (KEM) scheme based on the NTRU encryption scheme. The KEM is an existing cryptographic system; no new cryptography is defined herein. The well-defined and reviewed parameter sets for the scheme are defined and recommended. The test vectors are also provided. | |||||||||||||
| Secret Key Agreement for DNS: The TKEY Resource Record | ||||||||||||||
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. | |||||||||||||
| Managing CBOR codepoints in Internet-Drafts | ||||||||||||||
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. | |||||||||||||
| EVPN Inter-Domain Option-B Solution | ||||||||||||||
|
An EVPN Inter-Domain interconnect solution is required when two or more sites of the same Ethernet Virtual Private Network (EVPN) are connected to different IGP domains or Autonomous Systems (AS) and need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for this type of EVPN connectivity. While multiple documents describe aspects of this interconnect approach, there is no single document that summarizes the impact of Inter-Domain Option-B connectivity on EVPN procedures. This document does not define new procedures; rather, it analyzes the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the issues identified. These solutions are either based on existing specifications or rely on local implementations that do not modify the end-to-end EVPN control plane. | |||||||||||||
| The MASQUE Proxy | ||||||||||||||
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. | |||||||||||||
| BFD Path Consistency over SR | ||||||||||||||
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy | |||||||||||||
| Purge Originator Identification for OSPF | ||||||||||||||
|
In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. | |||||||||||||
| SCION Control Plane | ||||||||||||||
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| Using onion routing with CoAP | ||||||||||||||
|
The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and of clients similar to how Tor (onion routing) enables it for TCP-based protocols. | |||||||||||||
| Multiple Algorithm Rules in DNSSEC | ||||||||||||||
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. | |||||||||||||
| Deterministic Networking (DetNet) Data Plane - Flow interleaving for scaling detnet data planes with minimal end-to-end latency and large number of flows. | ||||||||||||||
|
This memo explain requirements, benefits and feasibility of a new DetNet service function tentatively called "flow interleaving". It proposes to introduce this service function into the DetNet architecture. Flow interleaving can be understood as a DetNet equivalent of the IEEE TSN timed gates. Its primary role is intended to be at the ingress edge of DetNet domains supporting higher utilization and lower bounded latency for flow aggregation (interleaving of flows into a single flow), as well as higher utilization and lower bounded latency for interleaving occurring in transit hops of the DetNet domain in conjunction with in-time per-hop bounded latency forwarding mechanisms. | |||||||||||||
| Data Generation and Optimization for Network Digital Twin | ||||||||||||||
|
Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network in various what-if scenarios. Recently, Artificial Intelligence (AI) models, especially neural networks, have been applied for NDT modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model quality from the data perspective. | |||||||||||||
| AI-Based Distributed Processing Automation in Network Digital Twin | ||||||||||||||
|
This document discusses the use of AI technology and digital twin technology to automate the management of computer network resources distributed across different locations. Digital twin technology involves creating a virtual model of real-world physical objects or processes, which is utilized to analyze and optimize complex systems. In a network digital twin, AI-based network management by automating distributed processing involves utilizing deep learning algorithms to analyze network traffic, identify potential issues, and take proactive measures to prevent or mitigate those issues. Network administrators can efficiently manage and optimize their networks, thereby improving network performance and reliability. AI-based network management, utilizing network digital twin technology, also aids in optimizing network performance by identifying bottlenecks in the network and automatically adjusting network settings to enhance throughput and reduce latency. By implementing AI-based network management through automated distributed processing, organizations can improve network performance, and reduce the need for manual network management tasks. | |||||||||||||
| Advertise NRP Group extensions for IGP | ||||||||||||||
|
Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes,structures, and functions so that each slice can be dedicated to specific services or customers. A Network Resource Partition (NRP) is a collection of resources in the underlay network. Each NRP is used as the underlay network construct to support one or a group of IETF network slice services. This document describes an IGP mechanism that is used to advertise a large number of NRPs into a smaller number of NRP groups. | |||||||||||||
| EVPN Anycast Multi-Homing | ||||||||||||||
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function supports load balancing of unicast traffic from remote Network Virtualization Edge (NVE) devices to NVEs that are multi-homed to the same CE, regardless of whether the CE’s MAC/IP information has been learned on all those NVEs. This document introduces an optional enhancement to the EVPN multi-homing Aliasing function, referred to as EVPN Anycast Multi- homing. This optimization is specific to EVPN deployments over NVO3 tunnels (i.e., IP-based tunnels) and may offer benefits in typical data center designs, which are discussed herein. | |||||||||||||
| MIMI Portability | ||||||||||||||
|
This document describes MIMI Portability mechanisms. | |||||||||||||
| MIMI Attachments | ||||||||||||||
|
This document describes MIMI Attachments. | |||||||||||||
| Considerations For Maintaining Protocols Using Grease and Variability | ||||||||||||||
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. | |||||||||||||
| Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies | ||||||||||||||
|
The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. | |||||||||||||
| SCION Data Plane | ||||||||||||||
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION Data Plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| Classic McEliece | ||||||||||||||
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. 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-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. | |||||||||||||
| Enhanced Use Cases for Scaling Deterministic Networks | ||||||||||||||
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video, intelligent computing, and ISAC-enabled smart factory and outlines the common properties implied by these use cases. | |||||||||||||
| Opportunistic TCP-AO with TLS | ||||||||||||||
|
This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. | |||||||||||||
| BGP over TLS/TCP | ||||||||||||||
|
This document specifies the utilization of TCP/TLS to support BGP. | |||||||||||||
| Datagram Transport Layer Security (DTLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document defines a key-management solution based on Datagram Transport Layer Security 1.3 (DTLS) to protect the content of Stream Control Transmission Protocol (SCTP) packets using the packet protection framework provided by the SCTP DTLS chunk. The combination provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re-authentication and rekeying with ephemeral key exchange. The key-management solution does not require any additional defined features or implementation support beyond core DTLS 1.3. This is intended as a replacement to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). | |||||||||||||
| Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. | |||||||||||||
| MLS Virtual Clients | ||||||||||||||
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. | |||||||||||||
| X-Wing: general-purpose hybrid post-quantum KEM | ||||||||||||||
|
This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. | |||||||||||||
| Bicone Source Address Validation | ||||||||||||||
|
The primary design goal of source address validation (SAV) is avoiding improper blocks (i.e., blocking legitimate traffic) while maintaining directionality (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) for an Autonomous System (AS) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter which contains prefixes exclusively belonging to the provider cone. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. | |||||||||||||
| Characterization and Benchmarking Methodology for Power in Networking Devices | ||||||||||||||
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. | |||||||||||||
| The Asynchronous Remote Key Generation (ARKG) algorithm | ||||||||||||||
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. | |||||||||||||
| Discovery of Network-designated OSCORE-based Resolvers: Problem Statement | ||||||||||||||
|
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. | |||||||||||||
| Applicability of GMPLS and PCEP for fine grain Optical Transport Network | ||||||||||||||
|
ITU-T Recommendation ITU-T G.709/Y.1331 (2020) Amd.3 (03/2024) introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. | |||||||||||||
| Compute-Aware Traffic Steering for Midhaul Networks | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. This document described the usage of Computing-Aware Traffic Steering (CATS) within Midhaul (MH) networks in the O-RAN architecture. It details how CATS can enhance traffic steering decisions between Distributed Units (DUs) and Centralized Units (CUs) by considering both compute resource metrics (e.g., CPU and memory utilization of CU instances) and network performance metrics (e.g., bandwidth, latency, reliability). The document discusses the integration of CATS with O-RAN management frameworks, and the interplay with the Transport Network Manager (TNM) in O-RAN using standard interfaces defined by IETF (as for example the one for Network Slice Services for connectivity provisioning). | |||||||||||||
| Self-Clocked Rate Adaptation for Multimedia | ||||||||||||||
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. This specification obsoletes RFC 8298. | |||||||||||||
| PQ/T Hybrid KEM: HPKE with JOSE/COSE | ||||||||||||||
|
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. | |||||||||||||
| Filtering Out RPKI Data by Type based on Enhanced SLURM Filters | ||||||||||||||
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. | |||||||||||||
| 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. 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 vetted entities and validated assertion of associated metadata. | |||||||||||||
| IGP Extensions for Optimized SRv6 SID Advertisement | ||||||||||||||
|
When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance. | |||||||||||||
| Attester Groups for Remote Attestation | ||||||||||||||
|
This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. | |||||||||||||
| Pacing in Transport Protocols | ||||||||||||||
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. | |||||||||||||
| Logging over Media over QUIC Transport | ||||||||||||||
|
Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. | |||||||||||||
| PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters | ||||||||||||||
|
This document defines PQ/T composite schemes based on ML-KEM and ML- DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol. | |||||||||||||
| SLAAC Prefixes with Variable Interface ID (IID) Problem Statement | ||||||||||||||
|
In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. | |||||||||||||
| SLAAC Prefixes with Variable Interface ID (IID) | ||||||||||||||
|
This draft proposes the use of a longer prefixes in PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits. This would eliminate the race to the bottom concerns. This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. | |||||||||||||
| Mobile Traffic Steering | ||||||||||||||
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. | |||||||||||||
| SRv6 Inter Domain Routing | ||||||||||||||
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. | |||||||||||||
| On Numbers in CBOR | ||||||||||||||
|
The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers and implementers of CBOR libraries and of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is a rather drafty initial revision, pieced together from // various components, so it has a higher level of redundancy than // ultimately desired. | |||||||||||||
| IS-IS Extension for Big TLV | ||||||||||||||
|
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a solution to IS-IS extension for encoding the TLV whose value is bigger than 255 octets. | |||||||||||||
| Domain variant support for EPP | ||||||||||||||
|
This document defines an EPP extension allowing clients to learn about and manipulate variant groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant. | |||||||||||||
| Current State of the Art for High Performance Wide Area Networks | ||||||||||||||
|
High Performance Wide Area Networks (HP-WANs) represent a critical infrastructure for the modern global research and education community, facilitating collaboration across national and international boundaries. These networks, such as Janet, ESnet, GÉANT, Internet2, CANARIE, and others, are designed to support the general needs of the research and education users they serve but also the the transmission of vast amounts of data generated by scientific research, high-performance computing, distributed AI-training and large-scale simulations. This document provides an overview of the terminology and techniques used for existing HP-WANS. It also explores the technological advancements, operational tools, and future directions for HP-WANs, emphasising their role in enabling cutting-edge scientific research, big data analysis, AI training and massive industrial data analysis. | |||||||||||||
| Automated Certificate Management Environment (ACME) Extension for Public Key Challenges | ||||||||||||||
|
This document specifies an extension to the ACME protocol [RFC8555] that enables Acme server to use the public key authentication protocol to verify that the real certificate applicant behind the Acme client has control over the identity and to ensure strong consistency between the identity in the challenge phase and the identity of the final certificate issued. This document also proposes a process extension for removing CSR at the certificate application phase. | |||||||||||||
| Terminology for Energy Efficiency Network Management | ||||||||||||||
|
Energy-efficient network management is primary meant to enhance conventional network management with energy-related management capabilities to optimize the overall energy consumption at the level of a network. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network element and their components. This document is defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. | |||||||||||||
| PQ/T Hybrid Composite Signatures for JOSE and COSE | ||||||||||||||
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. | |||||||||||||
| LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various Label Switched Path (LSP) identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. | |||||||||||||
| Designated Verifier Signatures for JOSE | ||||||||||||||
|
This specification defines structures and algorithm descriptions for the use of designated verifier signatures, based on a combination of Key Agreement and Message Authentication Code, with JOSE. | |||||||||||||
| AI based Network Management Agent(NMA): Concepts and Architecture | ||||||||||||||
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network or Intent-based Networking, and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. | |||||||||||||
| Serialization of MoQ Objects to Files | ||||||||||||||
|
This specification provides a way to save the metadata about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the metadata and payload data allows the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to clients. | |||||||||||||
| Applicability of TVR YANG Data Models | ||||||||||||||
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include resource preservation networks, operating efficiency networks and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. | |||||||||||||
| Calibration of Measured Time Values between Network Elements | ||||||||||||||
|
Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. To ensure consistency and accuracy across different network element implementations, a benchmarking procedure is necessary to calibrate the timestamps. Such a procedure can permit the identification and correction of any deviations or biases in the time stamps produced by diverse devices. This document proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. | |||||||||||||
| Flexicast QUIC: combining unicast and multicast in a single QUIC connection | ||||||||||||||
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. | |||||||||||||
| DHCPv4 Option for IPv4 routes with IPv6 nexthops | ||||||||||||||
|
As a result of the shortage of IPv4 addresses, installations are increasingly recovering IPv4 addresses from uses where they are not strictly necessary. One such situation is in establishing next hops for IPv4 routes, replacing this use with IPv6 addresses. This document describes how to provision DHCP-configured hosts with their routes in such a situation. // This draft lives at https://github.com/eqvinox/dhc-route4via6 | |||||||||||||
| A YANG Data Model for Passive Network Inventory | ||||||||||||||
|
This document presents a YANG data model for tracking and managing passive network inventory. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. | |||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| A Password Authenticated Key Exchange Extension for TLS 1.3 | ||||||||||||||
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. | |||||||||||||
| SRv6 Inter Domain Routing Architecture | ||||||||||||||
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. | |||||||||||||
| SRv6 Inter Domain Routing Use Cases | ||||||||||||||
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. | |||||||||||||
| Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm | ||||||||||||||
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. | |||||||||||||
| Controlling IP Fragmentation on Common Platforms | ||||||||||||||
|
When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. | |||||||||||||
| Scalable Quality Extension for the Opus Codec (Opus HD) | ||||||||||||||
|
This document updates RFC6716 to add support for a scalable quality layer. | |||||||||||||
| Use Cases for Energy Efficiency Management | ||||||||||||||
|
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-stephan-green-use-cases | |||||||||||||
| Lightweight Secure Shell (SSH) Signature Format | ||||||||||||||
|
This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. | |||||||||||||
| Split signing algorithms for COSE | ||||||||||||||
|
This specification defines COSE algorithm identifiers used when one signing operation is split between two cooperating parties. When performing split signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited-bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. | |||||||||||||
| 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. | |||||||||||||
| SRv6 Policy SID List Optimization Advertisement | ||||||||||||||
|
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 BGP-LS extension to indicate whether the endpoint's node SID is included or excluded in installing SID list(s) of the Candidate Path (CP) of an SRv6 policy. | |||||||||||||
| An Architecture for IP in Deep Space | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-24 minutes) and intermittent communications, because of orbital dynamics. The IP protocol stack used on Earth's Internet is based on assumptions of shorter delays and mostly uninterrupted communications. This document describes the architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configuration and application protocol timers. This architecture applies to the Moon, Mars, or general interplanetary networking. | |||||||||||||
| A Public Key Service Provider for Verification in Multiple Issuers and Verifiers | ||||||||||||||
|
SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure. | |||||||||||||
| JWTClaimConstraints profile of ACME Authority Token | ||||||||||||||
|
This document defines an authority token profile for handling the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. This profile follows the model established in Authority Token for the validation of TNAuthList but is specifically tailored for the JWTClaimConstraints certificate extensions. The profile enables validation and challenge processes necessary to support certificates containing both TNAuthList and JWTClaimConstraints, particularly in the context of Secure Telephone Identity (STI). | |||||||||||||
| 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. | |||||||||||||
| Large Model based Agents for Network Operation and Maintenance | ||||||||||||||
|
Current advancements in AI technologies, particularly large models, have demonstrated immense potential in content generation, reasoning, analysis and so on, providing robust technical support for network automation and self-intelligence. However, in practical network operations, challenges such as system isolation and fragmented data lead to extensive manual, repetitive, and inefficient tasks, the improvement of intelligence level is very necessary. This document identifies typical scenarios requiring enhanced intelligence, and explains how AI Agents and large model technologies can empower networks to address operational pain points, reduce manual efforts, and explore impacts on network data, system architectures, and interfaces correspondingly. It further explores and summarizes standardization efforts in implementation. | |||||||||||||
| Remote Attestation with Multiple Verifiers | ||||||||||||||
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. 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-rats/draft-deshpande-multi-verifier. | |||||||||||||
| YANG Datastore Telemetry (YANG Push Lite) | ||||||||||||||
|
YANG Push Lite is a YANG datastore telemetry solution, as an alternative specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. | |||||||||||||
| KEM based Authentication for the IKEv2 with Post-quantum Security | ||||||||||||||
|
This draft specifies a new authentication mechanism, called KEM based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. This is motivated by the fact that ML-KEM is much more efficient that ML-DSA, which are the post-quantum algoirhtms for mitigating the pontential security threats again quantum computers. The KEM based authenticationth for the IKV2 is achieved via introduing a new value of the IKEv2 Authentication Method registry mantained by IANA. For using the new authentication method, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined by [RFC9593]，to negotiate the supported KEM algorithms. After that, the correponding KEM certificates and cipthertext are exchanged via the INTERMEDIATE Exchange. Finally，the IKE messages are authenticated via the shared secret encapsulated between the two peers. This documents also specifies the instantiation with ML-KEM for this new general authenticaiton method for the IKEv2. [EDNOTE: Code points for KEM-based authentication may need to be assigned in the IKEv2 Authenticaion Method registry, maintained by IANA] | |||||||||||||
| YANG Data Model for supporting multipath IGMP/MLD proxies | ||||||||||||||
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. | |||||||||||||
| Multipath Traffic Engineering | ||||||||||||||
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, nor the load balancing equally weighted to each next hop. Moreover, the desired destination may be reachable via multiple egresses. The proposal includes a protocol for signaling MPTE paths using various types of tunnels, some of which are better suited to multipathing. | |||||||||||||
| 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. | |||||||||||||
| Secure Asset Transfer Protocol (SATP) Implementation Guide | ||||||||||||||
|
This memo provides guidelines to developers of gateway systems, digital asset networks and client applications for the Secure Asset Transfer Protocol (SATP). Multiple gateways can represent the same digital asset network following the SATP standards, which necessitate basic implementation guidelines as outlined in this document. It also serves as an introduction to the SATP processing workflow for those new to the SATP standards. | |||||||||||||
| MoQT Test | ||||||||||||||
|
This document specifies the moq-test protocol, a testing protocol for Media over QUIC (MOQ) implementations. moq-test utilizes the Track Namespace as parameters to the publisher, enabling flexible and customizable testing scenarios. | |||||||||||||
| 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]. ] | |||||||||||||
| Architectural Considerations for Environmentally Sustainable Internet Technology | ||||||||||||||
|
This document discusses protocol and network architecture aspects that may have an impact on the sustainability of network technology. The focus is on providing guidelines that can be helpful for protocol designers and network architects, where such guidelines can be given. | |||||||||||||
| DKIM2 Procedures for bounce processing | ||||||||||||||
|
This memo provides a description of the procedures for bounce processing that should be performed by any mail system that implements DKIM2, as part of the overall DKIM2 protcol definition. | |||||||||||||
| Synchronizing caches of DNS resolvers | ||||||||||||||
|
Network of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. | |||||||||||||
| Congestion Control Based on SRv6 Path | ||||||||||||||
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. | |||||||||||||
| Framework for Energy Efficiency Management | ||||||||||||||
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network’s functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. | |||||||||||||
| Requirements of Fast Notification for Traffic Engineering and Load Balancing | ||||||||||||||
|
This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver timely network status updates directly from the network device with a change to the device expected to react to it. FaNTEL supports fast failure and congestion notifications, enabling rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, enhancing service reliability and performance. | |||||||||||||
| Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing | ||||||||||||||
|
Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability. | |||||||||||||
| Using ECN when Proxying UDP in HTTP | ||||||||||||||
|
This document describes how to proxy the ECN bits when proxying UDP in HTTP. | |||||||||||||
| 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. | |||||||||||||
| Domain Name Specification for DKIM2 | ||||||||||||||
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. | |||||||||||||
| The Use Cases for Optimizing Transport Layer Protocols in LEO and MEO Satellite Networks | ||||||||||||||
|
This document introduces the use cases for the performance of existing transport protocols in LEO and MEO satellite networks. The use cases identify and demonstrate the current challenges faced by transport layer protocols in these environments. | |||||||||||||
| An Intent Translation Framework for IoT Networks | ||||||||||||||
|
The evolution of 6G networks and the expansion of Internet of Things (IoT) environments introduce new challenges in managing diverse networked resources. Intent-based management frameworks enable operators to express desired network outcomes using high-level intents, often articulated in natural language. However, converting these expressions into machine-executable policy configurations remains an open challenge. This document defines an intent translation framework designed to bridge the gap between user-issued intents and structured policy representations for 6G enabled IoT systems. The framework accepts natural language intent as input and produces a policy document in a structured format, such as YAML, that aligns with the intent model defined in 3GPP in [TS-28.312]. The framework consists of modular components responsible for processing input, aligning user intent with domain knowledge, evaluating semantic confidence, and generating standardized output. This modularity supports transparency, interoperability, and automated policy enforcement in next-generation network infrastructures. | |||||||||||||
| Source Prefix Advertisement for Inter-domain SAVNET | ||||||||||||||
|
This document proposes to use Source Prefix Advertisement (SPA) messages for advertising hidden source prefixes and discovering the hidden paths of source prefixes. The accuracy of existing inter- domain SAV mechanisms like EFP-uRPF can be improved by SPA. | |||||||||||||
| Signaling Solution for HP-WAN | ||||||||||||||
|
This document proposes a technical solution for the host-network collaboration signaling to enhance the congestion control in High- Performance Wide Area Networks (HP-WAN). It also describes the RSVP extensions as an instantiation of this signaling solution. | |||||||||||||
| An Integrated Security Service System for 5G Networks using an I2NSF Framework | ||||||||||||||
|
This document presents an integrated framework for automated security management in 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system leverages Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are then translated into enforceable network and application policies. Network-level policies are delivered to 5G core components via the Network Exposure Function (NEF), while application-level policies are enforced directly at user equipment through distributed IBN Controllers. This architecture supports adaptive, context-aware, and distributed policy enforcement, enabling real-time response to dynamic edge conditions and user mobility scenarios such as handovers. By integrating closed-loop monitoring and analytics, the system ensures consistent and autonomous security across heterogeneous 5G environments. | |||||||||||||
| Crawler best practices | ||||||||||||||
|
This document describes best pratices for web crawlers. 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/garyillyes/cbcp. | |||||||||||||
| Applicability of Service & Infrastructure Maps (SIMAP) to Transport Networks | ||||||||||||||
|
This document explores the applicability of the Service & Infrastructure Maps (SIMAP) concepts to transport networks and it examines the YANG data models defined by the IETF to support the requirements and use cases for SIMAP applicability to transport networks. | |||||||||||||
| Considerations of AI-powered Autonomic Service Agent Communication | ||||||||||||||
|
ANIMA defined Autonomic Service Agent to build intelligent management functions into network devices, and could interact with each other through a standard protocol (aka GRASP).With the rapid advancement of Large Language Model (LLM)-driven AI technologies, there is now a potential opportunity to enhance the ASA to be AI-powered, thereby elevating the intelligence of device-built-in management functions to a whole new level.This document analyzes the impact of the AI-powered ASA, mostly from the perspective of the ASA communication protocol. | |||||||||||||
| The Impact of AI Agent to Network Infrastructure | ||||||||||||||
|
This document disucss and analyses the impact of AI Agent on network infrastructure aiming to facilitate the discussion and standardization about AI Agent communication within IETF. | |||||||||||||
| Basic Requirements for IPv6-only Provider Edge Routers | ||||||||||||||
|
This document specifies the basic requirements for multi-domain IPv6-only Provider Edge (PE) routers. The requirements cover several key aspects: support for fundamental IPv6 protocols, such as, MP-BGP and ICMPv6, implementation of 4map6 based MP-BGP extensions, stateless encapsulation and translation functions using IPv6 mapping prefixes as well as support for SRv6 and NAT64 functionalities. By defining these requirements, this document aims to facilitate the development, deployment and interoperability of such PE routers, thereby promoting the smooth establishment and operation of multi- domain IPv6-only Networks. | |||||||||||||
| SRv6 TE Endpoint Protection | ||||||||||||||
|
SRv6 TE achieves precise traffic engineering by strictly defining the traffic path (e.g., specifying particular nodes or links) through a predefined SID list. To address the failure of TI-LFA FRR protection in SRv6 TE Policy scenarios due to strict node constraints, this paper proposes an SRv6 designated Midpoint protection. | |||||||||||||
| Transport Network Level Use Cases | ||||||||||||||
|
With the continuous growth of business volume, the transmission rate and number of network elements have increased sharply, and energy consumption of transport network has increased accordingly. Rising power costs due to significant energy consumption in transport networks necessitate energy-saving measures. To address this, adjusting energy consumption strategies according to different service requirements to optimize efficiency, ensuring quality while eliminating waste. Furthermore, regular network optimization and energy efficiency assessments enhance equipment performance and extend lifespan, thereby controlling long-term operational costs. Integrating energy-saving concepts into transport network operations proactively supports sustainable development. This document presents two transport network level GREEN use cases, aiming to facilitate discussions within the GREEN Working Group on the potential benefits, challenges, and requirements. The use cases follow a structured template that is proposed for all GREEN use cases, ensuring consistency and comparability across different scenarios. | |||||||||||||
| Extending Trusted Path Routed: Issues in Runtime Trust Assessment and Monitoring | ||||||||||||||
|
This document outlines architectural challenges and open issues in extending the Trusted Path Routing model to include runtime trust assessment and monitoring. It is intended as input to ongoing discussions within the RATS and Trusted Path Routing work. | |||||||||||||
| A Protocol-agnostic Multiple Agents Interaction Model for Autonomous Network | ||||||||||||||
|
In the push toward Level 4 Autonomous Networks, CSPs must to adopt new processes and organizational changes, along with function-centric building blocks for higher autonomy. As intelligent agents evolve, network autonomy increasingly relies on deploying these agents, enabling self-management, self-healing, and adaptation with minimal human intervention. These agents facilitate the transition toward fully autonomous network operations across multiple layers, including services and resources. However, achieving Level 4 autonomy, where networks independently handle tasks across various domains, presents significant challenges, notably secure, efficient, and accurate multi-agent interactions. This document introduces a protocol- agnostic data model that enables multiple intelligent agents to communicate effectively using the model, ensuring end-to-end task execution and closed-loop operations in autonomous networks. | |||||||||||||
| KEM-based Authentication for EDHOC | ||||||||||||||
|
This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. | |||||||||||||
| External Relationship model for SIMAP | ||||||||||||||
|
abstract | |||||||||||||
| KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios | ||||||||||||||
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. | |||||||||||||
| Applying BGP-LS Traffic Engineering Extensions to BGP-LS-SPF | ||||||||||||||
|
This documents propose to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering(TE) to the BGP-LS-SPF SAFI. | |||||||||||||
| Decentralized RPKI Repository Architecture | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) plays a crucial role in securing inter-domain routing. However, the current RPKI Repository system suffers from fundamental limitations in reliability, scalability, and security. In particular, single-point failures at repository publication points (PPs), the growing number of bidirectional connections with relying parties (RPs), and the lack of mechanisms to mitigate misbehavior by certification authorities (CAs) pose significant risks to the integrity, authority, and resilience of the global RPKI ecosystem. This document proposes the Decentralized RPKI Repository (dRR), a novel repository architecture that decouples RPKI object signing from data distribution. dRR introduces a distributed federation of certificate servers (CSs) and a layer of Monitors to achieve robust, scalable, and auditable RPKI data management. The architecture maintains full compatibility with the existing RPKI trust model rooted in the five RIR trust anchors, enabling incremental deployment without disrupting current relying parties (RPs) validation semantics. By doing so, dRR addresses longstanding repository challenges and enhances the overall trustworthiness and efficiency of RPKI-based routing security. | |||||||||||||
| Integration of Remote Attestation with Key Negotiation and Distribution | ||||||||||||||
|
This draft proposes a lightweight security enhancement scheme based on remote attestation—key negotiation integrated into remote attestation. Organically integrating the main steps of end-to-end key negotiation into the remote attestation process may provide more security and flexibility. | |||||||||||||
| Problem Statement and Gap Analysis for Agent-enabled Mobile Core Network | ||||||||||||||
|
This document provides the problem statement and gap analysis of agent-enabled mobile core network. | |||||||||||||
| AI Agent Use Cases and Requirements in 6G Network | ||||||||||||||
|
This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. | |||||||||||||
| Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network | ||||||||||||||
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in MPLS networks. By extending existing OAM mechanisms such as ping, traceroute, the proposed solution enables comprehensive NRP support in MPLS networks. | |||||||||||||
| BGP Specific Route Refresh | ||||||||||||||
|
In certain scenarios, a BGP router may not require its peer to update all routes within an address family, but rather only the specific routes it needs. For example, in an EVPN network, a router might only require updates for all MAC/IP Advertisement Routes or all IP Prefix Advertisement Routes, or even just a subset of IP Prefix routes. This document presents a method for requesting the update of specific routes from a peer, thereby minimizing the impact of additional BGP updates. | |||||||||||||
| DNS data representation for use in RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document proposes a unified, extensible JSON representation for DNS resource records for use in the RESTful Provisioning Protocol (RPP). The aim is to create a single, consistent structure for provisioning all DNS-related data - including delegation, DNSSEC, and other record types - that directly mirrors the DNS data model and being mappable to existing EPP model of requests and responses same time. This approach simplifies the adoption of both current and future DNS features by aligning the provisioning format with the target system, thereby streamlining the management of domain names and related objects within RPP. | |||||||||||||
| Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option | ||||||||||||||
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE option, where the field Partial IV specifies the sequence number value used by the message sender. In the interest of encrypting as much information as reasonably possible, this document defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option. Therefore, it updates RFC 8613. Combined with the update of OSCORE identifiers, the encryption of Partial IV values helps counteracting on-path adversaries that attempt to correlate the sequence numbers observed in different network paths, in order to track OSCORE endpoints that perform a network path migration. The defined encryption method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). | |||||||||||||
| Generative AI for Intent-Based Networking | ||||||||||||||
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. | |||||||||||||
| A YANG Data Model for SIMAP | ||||||||||||||
|
This document defines a YANG data model for Service & Infrastructure Maps (SIMAP). It extends the RFC8345 YANG modules to support all SIMAP requirements. This document will only focus on modelling proposal for each of the requirements not supported by RFC8345. Any related terminology, concepts, use cases and requirements are defined outside of this draft and this draft will only refer to them, analyze how to model and propose the implementation solutions. | |||||||||||||
| In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) allows two peers to compute a shared secret session key. Once the session key is available, the two peers can use the EDHOC_Exporter interface, e.g., to derive keying material for an application protocol. This document defines an in-band approach that can be used by the two peers to agree about the lengths of the outputs produced with the EDHOC_Exporter interface. The defined approach relies on an EDHOC External Authorization Data (EAD) item that can be exchanged in the first two EDHOC messages of an EDHOC session. | |||||||||||||
| Multipath TCP with external keys | ||||||||||||||
|
This document proposes an extension to Multipath TCP that allows application layer protocols such as TLS or SSH to provide keys to authenticate the creation of new subflows. | |||||||||||||
| Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP | ||||||||||||||
|
This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. | |||||||||||||
| Reclassifying NAT64 (RFC6146) to Internet Standard | ||||||||||||||
|
This document reclassifies Stateful NAT64 ([RFC6146]) to Internet Standard. | |||||||||||||
| CNI Telco-Cloud Benchmarking Considerations | ||||||||||||||
|
This document investigates benchmarking methodologies for Kubernetes Container Network Interfaces (CNIs) in Edge-to-Cloud environments. It defines performance, scalability, and observability metrics relevant to CNIs, and aligns with the goals of the IETF Benchmarking Methodology Working Group (BMWG). The document surveys current practices, introduces a repeatable benchmarking frameworks (e.g., CODEF), and proposes a path toward standardized, vendor-neutral benchmarking procedures for evaluating CNIs in microservice-oriented, distributed infrastructures. | |||||||||||||
| Multipath TCP with longer DSS mappings | ||||||||||||||
|
This document proposes an extension to improve Multipath TCP based on operational experience by allowing Multipath TCP to use DSS mappings that are longer than 64 KBytes. | |||||||||||||
| Reclassifying RFC6052 to Internet Standard | ||||||||||||||
|
This document reclassifies IPv6 Addressing of IPv4/IPv6 Translators ([RFC6052]) to Internet Standard. | |||||||||||||
| Reclassifying EAM (RFC7757) to Internet Standard | ||||||||||||||
|
This document reclassifies Explicit Address Mappings for Stateless IP/ICMP Translation ([RFC7757]) to Internet Standard. | |||||||||||||
| IETF Network Slice Service Benchmarking | ||||||||||||||
|
Network slicing aims to provide assurance of specific network performance objectives for network services which require both connectivity and specific performance commitment. Such network services are considered as network slice services. This document provides a benchmarking methodology for network slicing, focusing on evaluating the key functionalities of network slicing mechanisms and the performance of network slice services. The network slicing functionalities includes the data plane, control plane and management plane mechanisms for realizing network slice service, and the performance of network slice service includes the service level agreement (SLA) commitments (bandwidth, delay, and jitter), path constraints and resource guarantee. The tests aim to demonstrate how network slicing can support competing services in a shared network, ensuring that critical network services in one network slice remain unaffected by congestion or unexpected behavior of other traffic in the same network. | |||||||||||||
| Knowledge Graph for Network Traffic Monitoring and Analysis | ||||||||||||||
|
This document extends the knowledge graph framework to the field of traffic monitoring, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. | |||||||||||||
| Reclassifying SIIT (RFC7915) to Internet Standard | ||||||||||||||
|
This document reclassifies IP/ICMP Translation Algorithm ([RFC7915]) to Internet Standard. | |||||||||||||
| ECN and DSCP support for HTTPS's Connect-UDP | ||||||||||||||
|
HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. QUIC and Real-time transport protocol (RTP) are examples of transport protocols that use UDP and support Explicit Congestion Notification (ECN) and provide the necessary feedback. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP. | |||||||||||||
| Energy-aware Routing Using Flex-Algo in Segment Routing | ||||||||||||||
|
This document proposes enhancements to the Segment Routing (SR) Flexible Algorithm (Flex-Algo) framework by integrating power consumption metrics into routing decisions. It introduces metrics encompassing both node-level and link-level energy consumption attributes and proposes dynamic energy-aware path computation. By incorporating these metrics alongside traditional routing parameters, the enhanced Flex-Algo framework can enable networks to optimize routing paths for energy efficiency, and then leverage on advances router capabilities to further reduce operational costs as well as supporting sustainability objectives. | |||||||||||||
| Workload Identifier Scope Hint for TLS ClientHello | ||||||||||||||
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier scopes in the ClientHello message. Each scope consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier scopes serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). | |||||||||||||
| Secondary Certificate Authentication of HTTP Clients | ||||||||||||||
|
This document defines a mechanism for HTTP/2 and HTTP/3 clients to provide additional certificate-based credentials after the TLS handshake has completed, using TLS Exported Authenticators. Unlike traditional client authentication during the TLS handshake, this mechanism allows clients to present multiple certificates over the lifetime of a session. | |||||||||||||
| DNS Protocol Modifications for Authoritative Delegation Point DNS Records | ||||||||||||||
|
This document proposes modifications to the Domain Name System (DNS) protocol to support a range of authoritative resource record types at delegation points. Currently, the DNS only allows DS (Delegation Signer) records at a delegation point as authoritative data. This draft extends that model by enabling the inclusion of a range of RRtypes at delegation points. The proposed modifications preserve compatibility with existing DNS resolution behavior while providing a clear framework for identifying and processing these records as authoritative data at delegation points. | |||||||||||||
| AI Agent protocols for 6G systems | ||||||||||||||
|
Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols. | |||||||||||||
| Extensions to TLS FATT Process | ||||||||||||||
|
This document proposes a new "Formal Analysis Considerations" section where the authors provide a threat model, informal security goals, and a protocol diagram. This document applies only to non-trivial extensions of TLS, which require formal analysis. | |||||||||||||
| MSD Consideration in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
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. Maximum SID Depth (MSD) specifies the maximum number of SIDs that a Path Computation Client (PCC) is capable of imposing on a packet. The number of SIDs in an SR-TE path computed by the PCE on behalf of a PCC is dictated by the MSD value at the PCC. This draft specifies some MSD considerations PCE needs to take into account when computing the number of SIDs in an SR-TE path. | |||||||||||||
| SRv6 BGP Unreachable Prefix Announcement (UPA) | ||||||||||||||
|
Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This mechanism, referred to as Unreachable Prefix Announcement (UPA), has been specified for IGPs. This document specifies an and equivalent BGP mechanism for multi-AS networks where BGP is used to carry summary routes. | |||||||||||||
| Static Context Header Compression Over 5G | ||||||||||||||
|
This document describes a possible integration of Static Context Header Compression [RFC8724] into 5G networks. | |||||||||||||
| YANG Data Model for Virtual Network Interfaces Management | ||||||||||||||
|
This document defines a YANG data model for the management of VNIs (Virtual Network Interfaces), including vNIC and CNI, depending on the different ways of virtualization. It exposes the real-time VNI resources to network controller and service orchestrator in order to supervise the cloud resource states for dynamic adjustment of service function placement and load-balancing of service instances to ensure the SLO (Service Level Objective). | |||||||||||||
| Consideration for IP-Based Satellite Routing Protocol | ||||||||||||||
|
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations. | |||||||||||||
| Supply Chain Use Cases to Design Secure Computing Systems for SCITT Extension | ||||||||||||||
|
This document includes a collection of representative Computational Supply Chain Use Cases. These use cases aim to identify computational supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. | |||||||||||||
| Hierarchical Topology for Language Model Coordination | ||||||||||||||
|
This document defines a YANG data model and reference architecture for a hierarchical topology of language models (LMs), where tiny, small, and large LMs cooperate to perform distributed inference, summarization, and decision-making. The model supports secure inter-node messaging, request escalation, token-based authorization, and decentralized validation using pluggable trust models. This architecture is designed for deployments where computational capabilities vary across nodes, such as edge-to-cloud environments or multi-tier AI systems. The goal is to provide a standards-based mechanism for orchestrating scalable, secure LM interactions across heterogeneous systems. | |||||||||||||
| BGP Extensions for Service Routing of Mobile Core Networks | ||||||||||||||
|
This document describes a new route propagation and service discovery mechanism by proposing BGP extensions for mobile core network service routing. The proposed solution introduces a Service Route Address Family, hierarchical Network Identifier allocation, and path-aware routing mechanisms that enable scalable inter-domain service discovery while preserving compatibility with current 3GPP standards. These extensions provide the foundation for efficient service propagation, route aggregation, and loop-free routing in large-scale distributed mobile core deployments. | |||||||||||||
| Multimodal Management Requirements for AI Agent Protocols | ||||||||||||||
|
This document specifies the Multimodal requirements for Agent-to- Agent Protocol, which enables autonomous agents to establish multi- channel communication sessions, negotiate heterogeneous data capabilities (e.g., text, file, real-time audio/video streams, sensor streams), and exchange synchronized multimodal content with adaptive QoS policies. | |||||||||||||
| A YANG Data Model for Reporting Utilization Scores in ISAC | ||||||||||||||
|
This document defines a basic YANG data model to report sensing measurements utilization score (US) in Integrated Sensing and Communication (ISAC) systems. The score quantifies the resource impact of different sensing measurements, including compute, memory, storage, energy, and latency. The model supports per-measurement telemetry reporting. | |||||||||||||
| AAuth - Agentic Authorization OAuth 2.1 Extension | ||||||||||||||
|
This document defines the Agent Authorization Grant, an OAuth 2.1 extension allowing a class of Internet applications - called AI Agents - to obtain access tokens in order to invoke web-based APIs on behalf of their users. In the use cases envisaged here, users interact with AI Agents through communication channels - the Public Switched Telephone Network (PSTN) or texting - which do not permit traditional OAuth grant flows. Instead, AI agents collect Personally Identifying Information (PII) through natural language conversation, and then use that collected information to obtain an access token with appropriately constrained scopes. A primary considering is ensuring that the Large Language Model (LLM) powering the AI Agent cannot, through hallucination, result in impersonation attacks. | |||||||||||||
| Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document defines how Datagram Transport Layer Security (DTLS) 1.3 is used to establish keys for securing SCTP using the DTLS Chunk mechanism. It specifies how a DTLS handshake is used to establish the initial security context for an SCTP association and describes procedures for key updates and post-handshake authentication. The goal is to enable authenticated, and confidential communication over SCTP using the DTLS Chunk, leveraging standardized DTLS features for key management and rekeying. | |||||||||||||
| The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, and easy to implement. | |||||||||||||
| LSP Ping/Traceroute for Prefix SID in Multi-Algorithm/Multi-Topology Networks | ||||||||||||||
|
[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. | |||||||||||||
| Multipath Traffic Engineering Capabilities | ||||||||||||||
|
Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of the tunnel. This memo shows how this information can be distributed in the IGP via Link State Routing TE Capabilities. | |||||||||||||
| Matching-first Route Origin Validation | ||||||||||||||
|
Route Origin Validation (ROV) using the Resource Public Key Infrastructure (RPKI) enables BGP routers to identify illegitimate routes that violate Route Origin Authorizations (ROAs). However, widespread deployment of RPKI requires validation systems to process high volumes of route announcements against increasingly large ROA datasets, where ROV adoption faces significant barriers due to concerns about its processing efficiency. This document identifies a performance issue inherent in current ROV procedure, which could be exacerbated as the expanding coverage of ROAs. | |||||||||||||
| RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. | |||||||||||||
| Delay-Tolerant Networking Architecture | ||||||||||||||
|
This document describes an architecture for delay-tolerant and disruption-tolerant networks. It is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a overlay protocol that interconnects multiple internets. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IETF DTN working group and has been widely reviewed by that group. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Multipath Traffic Engineered Directed Acyclic Graph (MPTED) Tunnels | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using Path Computation Element Communication Protocol (PCEP) in a stateful PCE model. | |||||||||||||
| Task-oriented Coordination Requirements for AI Agent Protocols | ||||||||||||||
|
AI agent communication requires intelligent task level coordination to manage dynamic workloads across large-scale, heterogeneous networking environments. This draft proposes general requirements for an agent protocol to enable autonomous task coordination at scale, including dynamic task discovery, negotiation, and context- aware scheduling with real-time adaptability. | |||||||||||||
| P2P Chat with MoQ | ||||||||||||||
|
This protocol is designed for small groups of users sending relatively small messages. It is optimized for the assumption that a node will come online and collect all messages at least once every 15 days and that some nodes that act as mirrors will be online most of the time but may come and go over long periods of time. | |||||||||||||
| Detecting the Presence of a Malicious Hub in MIMI Protocol | ||||||||||||||
|
This document defines a Merkle-tree-based approach that can act as an audit-layer detection mechanism to identify a malicious hub, responsible for interoperable group communication between various messaging platforms. The proposed approach is based on the MIMI protocol, which uses a central hub for timestamping and broadcasting messages to clients operating on different platforms. Even though all MLS ciphertexts are end-to-end encrypted, they are routed through the hub, making it a lucrative attack surface for message reordering attacks. To detect such attacks, the proposed approach suggests creating Merkle proofs of messages and timestamps on the client-side, which can subsequently be broadcast to other clients for verification with local Merkle proofs. The broadcast messages are encrypted too and are sent probabilistically to avoid being dropped by the hub. If any of the proofs do not match, an alert is broadcast to the room, indicating a malicious hub. The approach has minimal communication overhead for practical purposes. | |||||||||||||
| Post-quantum Hybrid Key Exchange with NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies the use of NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2), following the framework defined in RFC 9370. RFC 9370 introduces a mechanism that enables multiple key encapsulation mechanisms (KEMs) to be used within IKEv2, allowing up to seven additional key exchange methods to be negotiated alongside the initial key exchange. This document defines how NTRU can be used as an additional key exchange method to improve the post-quantum security of IKEv2 by broadening algorithmic diversity. [EDNOTE: IANA KE code points for NTRU will be needed to be assigned. ] | |||||||||||||
| Voice Conversation (vCon) Consent Attachment | ||||||||||||||
|
This document defines a consent attachment type for Voice Conversations (vCon), establishing standardized mechanisms for recording, verifying, and managing consent information within conversation containers. The consent attachment addresses privacy compliance challenges through structured metadata including consenting parties, temporal validity periods, and cryptographic proof mechanisms. The specification defines the mandatory and optional fields for consent attachments, including expiration timestamps, party references, dialog segments, and consent arrays. It supports granular consent management through purpose-based permissions and integrates with the AI Preferences vocabulary for automated processing systems. The attachment type incorporates SCITT (Supply Chain Integrity, Transparency, and Trust) for cryptographic transparency and provides integration patterns for consent ledger services. Key features include automated consent detection during conversation processing, auditable consent records with cryptographic proofs, support for consent revocation through superseding statements, and integration with existing privacy regulations. The consent attachment enables organizations to maintain compliance while providing sufficient structure for automated processing and verification of consent throughout the vCon lifecycle. | |||||||||||||
| Privacy Pass Authentication for Media over QUIC (MoQ) | ||||||||||||||
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. | |||||||||||||
| A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. | |||||||||||||
| Mapping Open Cybersecurity Schema Framework Events to Media over QUIC Transport | ||||||||||||||
|
This document defines a mapping specification for representing Open Cybersecurity Schema Framework (OCSF) events, categories, and profiles using Media over QUIC Transport (MOQT) tracks. The mapping leverages MOQT's hierarchical data model and publish/subscribe architecture to enable real-time, in-network cached, scalable distribution of cybersecurity event data across networks while maintaining OCSF's structured taxonomy and semantic relationships. | |||||||||||||
| 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. | |||||||||||||
| OAuth 2.0 Attestation-Based Client Authentication | ||||||||||||||
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. | |||||||||||||
| Token Status List (TSL) | ||||||||||||||
|
This specification defines a mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. | |||||||||||||
| A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) | ||||||||||||||
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. | |||||||||||||
| A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests | ||||||||||||||
|
This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes. | |||||||||||||
| Applying COSE Signatures for YANG Data Provenance | ||||||||||||||
|
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. | |||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. | ||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. | |||||||||||||
| 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. | |||||||||||||
| Multipath Support for IGMP/MLD Proxy | ||||||||||||||
|
This document describes multipath support for Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as channel/session IDs and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. | |||||||||||||
| PIM Flooding Mechanism and Source Discovery Enhancements | ||||||||||||||
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used to provide various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM deployments. | |||||||||||||
| qlog: Structured Logging for Network Protocols | ||||||||||||||
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| QUIC event definitions for qlog | ||||||||||||||
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| HTTP/3 qlog event definitions | ||||||||||||||
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| Multipath Extension for QUIC | ||||||||||||||
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. 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/quicwg/multipath. | |||||||||||||
| Extended Key Update for QUIC | ||||||||||||||
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. | |||||||||||||
| 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. | |||||||||||||
| Concise Reference Integrity Manifest | ||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. | |||||||||||||
| Remote Posture Assessment for Systems,Containers,and Applications at Scale | ||||||||||||||
|
This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. | |||||||||||||
| PKIX Evidence for Remote Attestation of Hardware Security Modules | ||||||||||||||
|
This document specifies a vendor-agnostic format for evidence produced and verified within a PKIX context. The evidence produced this way includes claims collected about a cryptographic module and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce evidence tailored for expected use. | |||||||||||||
| Common Ancestor Objective Function and Parent Set DAG Metric Container Extension | ||||||||||||||
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. | |||||||||||||
| Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements | ||||||||||||||
|
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. | |||||||||||||
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. | |||||||||||||
| Standard Communication with Network Elements (SCONE) Protocol | ||||||||||||||
|
This document describes a protocol where on-path network elements can give endpoints their perspective on what the maximum achievable throughput might be for QUIC flows. | |||||||||||||
| Structured vacation notices | ||||||||||||||
|
This document describes a machine-readable format for conveying unavailibility information in email messages. This includes "vacation notices" of persons but also different forms of unavailibility for emails sent by programs. Structured vacation notices are supposed to be used in conjunction with conventional, human-readable vacation notices in most cases. They are based on the forthcoming "structured email" specification defined in [I-D.ietf-sml-structured-email-03] and related drafts. | |||||||||||||
| Automatically Connecting Stub Networks to Unmanaged Infrastructure | ||||||||||||||
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). | |||||||||||||
| SPICE SD-CWT | ||||||||||||||
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. | |||||||||||||
| Use Cases for SPICE | ||||||||||||||
|
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation. | |||||||||||||
| YANG Data Model for SRv6 Base and Static | ||||||||||||||
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| SRv6 and MPLS interworking | ||||||||||||||
|
This document describes SRv6 and MPLS/SR-MPLS interworking procedures. Interworking problem is generalized into various interworking scenarios. These scenarios are stitched either by transport interworking or service interworking. New SRv6 behaviors are defined for the purpose. These new behaviors and MPLS labels stitch end to end path across different data plane. | |||||||||||||
| 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. | |||||||||||||
| Out-of-Band STIR for Service Providers | ||||||||||||||
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. | |||||||||||||
| Connected Identity for STIR | ||||||||||||||
|
The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework, however, provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog- terminating events by intermediaries or third parties. | |||||||||||||
| Encrypted Payloads in SUIT Manifests | ||||||||||||||
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. | |||||||||||||
| IETF Network Slice Application in 3GPP 5G End-to-End Network Slice | ||||||||||||||
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. | |||||||||||||
| IETF Network Slice Controller and its Associated Data Models | ||||||||||||||
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. | |||||||||||||
| A well-known URI for publishing service parameters | ||||||||||||||
|
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. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too. | |||||||||||||
| Extended Key Update for Transport Layer Security (TLS) 1.3 | ||||||||||||||
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows traffic keys to be refreshed during a session, it does not introduce new forward-secret key material. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby re-establishing forward secrecy beyond the initial handshake. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. | |||||||||||||
| Operational Guidance on Coexistence with Classic ECN during L4S Deployment | ||||||||||||||
|
This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. | |||||||||||||
| Configuring UDP Sockets for ECN for Common Platforms | ||||||||||||||
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. | |||||||||||||
| TVR (Time-Variant Routing) Requirements | ||||||||||||||
|
Time-Variant Routing (TVR) refers to calculating a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements where TVR computations could improve message exchange in a network. | |||||||||||||
| The WebTransport Protocol Framework | ||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. | |||||||||||||
| WebTransport over HTTP/3 | ||||||||||||||
|
WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. | |||||||||||||
| WebTransport over HTTP/2 | ||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | |||||||||||||
| Workload Identity in a Multi System Environment (WIMSE) Architecture | ||||||||||||||
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. | |||||||||||||
| Workload Identity Practices | ||||||||||||||
|
This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture [I-D.ietf-wimse-arch] and other protocols, such as [I-D.ietf-wimse-s2s-protocol]. | |||||||||||||
| Transmission of IPv6 Packets over Short-Range Optical Wireless Communications | ||||||||||||||
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) communications. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) | ||||||||||||||
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. | |||||||||||||
| BRSKI Cloud Registrar | ||||||||||||||
|
Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. This document extends BRSKI and defines new device behavior for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. | |||||||||||||
| Meticulous Keyed ISAAC for BFD Optimized Authentication | ||||||||||||||
|
This document describes a new BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the the "Up" state. | |||||||||||||
| A YANG Data Model for Network Tester Management | ||||||||||||||
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. | |||||||||||||
| The eap.arpa domain and EAP provisioning | ||||||||||||||
|
This document defines the eap.arpa domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers which use the Network Access Identifier (NAI) format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140. | |||||||||||||
| Dynamic Capability for BGP-4 | ||||||||||||||
|
This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. | |||||||||||||
| Key Transparency Architecture | ||||||||||||||
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. | |||||||||||||
| Key Transparency Protocol | ||||||||||||||
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. | |||||||||||||
| OSPF YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. | |||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. | |||||||||||||
| YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also specifies the initial version of IANA-maintained YANG modules for IGP Algorithm Types and IGP Metric-Type. | |||||||||||||
| YANG Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. | |||||||||||||
| A YANG Data Model for Network Incident Management | ||||||||||||||
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and probable cause analysis. | |||||||||||||
| Network Digital Twin: Concepts and Reference Architecture | ||||||||||||||
|
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concepts of Network Digital Twin, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. | |||||||||||||
| Cacheable OSCORE | ||||||||||||||
|
Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. | |||||||||||||
| BGP-LS extensions for BIER-TE | ||||||||||||||
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. | |||||||||||||
| EAP defaults for devices that need to onboard | ||||||||||||||
|
This document describes a method by which an unconfigured device can use EAP-TLS to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. | |||||||||||||
| BGP over QUIC | ||||||||||||||
|
This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. | |||||||||||||
| Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS) | ||||||||||||||
|
BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. | |||||||||||||
| Outer Header Translator - multihoming | ||||||||||||||
|
This document describes how to achieve multihoming using OHT. This document describes both the use of provider addresses and provider independent addresses. | |||||||||||||
| SRv6 NET-PGM extension: Compressed BSID Insertion | ||||||||||||||
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-C-SID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-C-SID flavor. | |||||||||||||
| A YANG Data Model of Performance Management Streaming | ||||||||||||||
|
This document provides a YANG data model of performance management streaming from network equipment to clients. It defines pm measurement methods, event notifications, generic pm parameters and streaming subscriptions. | |||||||||||||
| BGP SR Policy Extensions for Performance-Aware Path Selection | ||||||||||||||
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute [RFC9012]. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in [RFC4271], modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection | |||||||||||||
| 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). | |||||||||||||
| Modernizing Workload Security: Verifiable Geofencing,Proof-of- Possession,and Protocol-Aware Residency Enforcement | ||||||||||||||
|
Modern cloud and distributed environments face significant risks from stolen bearer tokens, protocol replay, and trust gaps in transit. This document presents a framework for modernizing workload security through cryptographically verifiable geofencing, proof-of-possession, and protocol-aware residency enforcement. By binding workload identity to both geographic and host attributes, and supplementing bearer tokens with verifiable, location- and host-bound claims, the framework addresses the challenges of bearer token theft, proof-of- possession and trust-in-transit for all networking protocols. Leveraging trusted hardware, attestation protocols, and geolocation services, this approach ensures that only authorized workloads in approved locations and environments can access sensitive data or services, even in the presence of advanced threats. | |||||||||||||
| Distributed Remote Attestation | ||||||||||||||
|
In the RATS architecture, remote attestation typically involves multiple roles: verifier, attester, endorser, reference value provider, and relying party. However, in complex networks, the large number of entities in each role can significantly increase the cost of communication and computational resources. This document proposes a simplified remote attestation method based on distributed ledger(DL) technology, which aims to reduce the overhead for participants in multi-party networks. | |||||||||||||
| Use cases in network operations in telco cloud | ||||||||||||||
|
This document presents two network operations in telco cloud orchestration use case for AI-based video recognition in smart city management and dynamic high-bandwidth transport. Key innovations include dynamic resource scheduling across heterogeneous computing (GPU/NPU) and network domains, centralized training with distributed inference, and low-latency data transmission compliant with data sovereignty requirements. Additionally, the use case demonstrates elastic bandwidth provisioning and failover mechanisms to ensure reliability. The framework highlights the need for standardized interfaces between cloud and network controllers to optimize performance, resource utilization, and QoS in telecom cloud environments. | |||||||||||||
| FANTEL scenarios and requirements in Wide Area Network | ||||||||||||||
|
This document introduces the main scenarios related to AI services in WAN, as well as the requirements for FANTEL(FAst Notification for Traffic Engineering and Load balancing) in these scenarios. Traditional network management mechanisms are often constrained by slow feedback and high overhead, limiting their ability to react quickly to sudden link failures, congestion, or load imbalances. Therefore, these new AI services need FANTEL to provide real-time and proactive notifications for traffic engineering and load balancing, meeting the ultra-high throughput and lossless data transmission requirements of these AI service scenarios. | |||||||||||||
| Fast Notification for Traffic Engineering and Load Balancing for tunnel-based lossless transmission in WAN | ||||||||||||||
|
With the rapid development of large language models, many emerging AI scenarios require tunnel-based lossless transmission of RDMA packets in WAN. To fulfill this requirement, WAN should support the real- time notification of network conditions to ensure high throughput, low latency, and zero packet loss data transmission. The current reactive notification solution is limited by responsiveness, coverage, and operational overhead. Therefore, we need to establish a faster and proactive notification mechanism to implement more responsive Traffic Engineering and Load Balancing. This draft first describes typical scenarios for tunnel-based RDMA lossless transmission in WAN, then specifies the fast notification framework for implementing key TE areas (congestion control, protection, and load balance), and finally analyses the protocol implementation for fast notification. | |||||||||||||
| Including Pending Proposals in External Commits in the Messaging Layer Security protocol | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol allows authorized non- members to join a group via external commits, however it disallows most pending proposals in those commits, which causes unfortunate side effects. This document describes an MLS extension to include pending proposal in external commits when the extension is present in a group. | |||||||||||||
| Multicast over SRv6 networks | ||||||||||||||
|
This document presents solutions for deploying multicast in SRv6 networks. It explores the use of the native IPv6 multicast data plane for multicast distribution. The document discusses distributed control plane mechanisms, including PIM, and its integration with IGP Flex-Algo to optimize multicast delivery. The document also addresses overlay multicast solutions for both the Global Table Multicast (GTM) and Multicast VPNs (MVPNs), utilizing IP-in- IPv6 encapsulation without requiring additional shim layers. | |||||||||||||
| Specification of Test Case Structure for Protocol Testing Automation | ||||||||||||||
|
This document defines a standardized test case specification used in automated network protocol testing. The specification aims to provide a structured and interoperable format for representing test cases that evaluate the implementations of network protocols. This work facilitates the development of protocol-agnostic testing frameworks and improves the repeatability and automation of network testing. | |||||||||||||
| Do Not Accommodate Classic DNS over UDP | ||||||||||||||
|
Protocols that rely on Classic DNS have to account for considerations that only apply to UDP, such as message fragmentation. However, DNS implementations are already required to support both TCP and UDP, and using TCP would alleviate these considerations. This document specifies that new protocols with a dependency on Classic DNS do not need to account for the limitations of Classic DNS over UDP and can instead expect implementations to use Classic DNS over TCP. | |||||||||||||
| SMTP Extensions for End-to-End Encryption and User-Level Signatures | ||||||||||||||
|
This Internet-Draft proposes adding extensions to the SMTP protocol that allow for true End-to-End Encryption and cryptographic signatures between users on a SMTP server. Current DKIM only allows for server verification, while messages sent through secure channels only encrypt traffic between servers, not between users. | |||||||||||||
| Energy-aware Differentiated Services (EA-DS) | ||||||||||||||
|
This document proposes to extend the Differentiated Services (DiffServ) Quality of Service (QoS) model to support energy-efficient networking. As a first draft, it discusses how such extensions could be done, bringing first examples of energy-efficiency metrics that could be applied to mark traffic, and providing routing applicability examples by interpreting existing or experimental DSCP codepoints to represent not only traditional QoS parameters (e.g., latency, jitter), but also application-level energy sensitivity. By incorporating energy metrics into traffic classification, network devices and orchestrators can make routing and resource allocation decisions that optimize both service performance and energy consumption. | |||||||||||||
| Associated IP Prefixes for Domain Names | ||||||||||||||
|
RFC9000 defines a mechanism that allows servers to migrate clients to another IP address without name resolution. The new address may not be discoverable as A/AAAA records for that domain name. This draft defines a mechanism that allows a client to get advance notice of associated IP addresses for a domain name as part of the DNS query. | |||||||||||||
| DNS-Based Address Mappping Record (AMR) for IPv4/IPv6 Mapping in IPv6-only Networks | ||||||||||||||
|
This document defines a new Domain Name System (DNS) resource record type called the Address Mapping Record (AMR). The AMR record enables querying of IPv6 mapping prefixes associated with the destination address of an IPv4 packet in IPv6-only networks. This mechanism facilities the transmission of IPv4 service data across multi-domain in IPv6-only environment, supporting IPv4-as-a-Service (IPv4aaS) implementations. | |||||||||||||
| Multicast usage in LLM MoE | ||||||||||||||
|
Large Language Models (LLMs) have been widely used in recent years. The Mixture of Experts (MoE) architecture is one of the features of LLMs that enables efficient inference and cost-effective training. With the MoE architecture, there are potential multicast use cases such as tokens dispatching. This draft attempts to analyze these use cases. | |||||||||||||
| Applicability of A2A to the Network Management | ||||||||||||||
|
This document discusses the applicability of A2A to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed. | |||||||||||||
| Applicability of IETF-Defined Service and Network Data Models for Telcocloud Network Management | ||||||||||||||
|
This document describes how the various data models that are produced in the IETF can be combined in the context of Telco Cloud service delivery. Specifically, this document describes the communication of a Network Orchestrator and Cloud orchestrator for the realization of optimized Telco Cloud services to implement inter-dc reachability and connectivity services. | |||||||||||||
| Enhanced ECMP for AI Cluster | ||||||||||||||
|
In AI training scenarios, the current mainstream load balancing technology is per-flow ECMP. However, hash collision issues lead to imbalanced traffic distribution, adversely affecting application performance. To address this problem, this document proposes an enhanced ECMP method that resolves load imbalance caused by hash collisions. The proposed solution effectively improves load balancing efficiency, reduces network congestion, and enhances overall network performance. | |||||||||||||
| Path MTU Algorithms and Issues in QUIC Applications | ||||||||||||||
|
This draft consider Path MTU (PMTU) alogorithms and issues in QUIC applications. Fistly, a passive probing approach is adopted to discover the PMTU. The process of discovering the PMTU is not performed separately, but is performed simultaneously in the actual application data communication. A probe packet is defined newly using 1-RTT packet which includes actual application data as well as a short packet header and a PING_EXT frame. Until the optimal PMTU is discovered, the size of the probe packet is changed according to the size of the PMTU candidate. Secondly, a PMTU black hole problem in secure and reliable transport protocol is discussed and a possible solution can be suggested from existing researches. Thirdly, PMTU issues for media delivery over UDP, such as WebRTC and media over QUIC (MoQ) are discussed. | |||||||||||||
| Stateless Encryption Scheme of Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This draft first introduces several use cases for stateless encryption, analyzes and compares some existing stateless encryption schemes in the industry, and then attempts to propose a general and flexible stateless encryption scheme based on the summarized requirements. | |||||||||||||
| Quantum-Resistant Cipher Suites for EDHOC | ||||||||||||||
|
The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-KEM for key exchange and ML-DSA for digital signatures. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. | |||||||||||||
| YANG Models for Quality of Service (QoS) in IP networks | ||||||||||||||
|
This document describes a YANG model for management of Quality of Service (QoS) in IP networks. | |||||||||||||
| 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. | |||||||||||||
| YANG Data Model for Topology Filter | ||||||||||||||
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. | |||||||||||||
| A recommendation for filtering address records in stub resolvers | ||||||||||||||
|
Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. | |||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | ||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | |||||||||||||
| Join Proxy for Bootstrapping of Constrained Network Elements | ||||||||||||||
|
This document extends the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a new network function, the constrained Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low- Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. | |||||||||||||
| Weighted Multi-Path Procedures for EVPN Multi-Homing | ||||||||||||||
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. | |||||||||||||
| Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. | |||||||||||||
| BGP Performance-aware Routing Mechanism | ||||||||||||||
|
The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-aware BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. | |||||||||||||
| Accumulated Metric in NHC attribute | ||||||||||||||
|
RFC7311 describes mechanism for carrying accumulated IGP cost across BGP domains however it limits to IGP-metric only. There is a need to accumulate and propagate different types of metrics as it will aid in intent-based end-to-end path across BGP domains. This document defines BGP extensions for generic metric sub-types that enable different types of metrics to be accumulated and carried in BGP. This is applicable when multiple domains exchange BGP routing information. | |||||||||||||
| IS-IS Distributed Flooding Reduction | ||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. | |||||||||||||
| Flooding Reduction Algorithms Framework | ||||||||||||||
|
This document introduces a framework to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. | |||||||||||||
| Discovery Of Restconf Metadata for Source-specific multicast | ||||||||||||||
|
This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. | |||||||||||||
| YANG Groupings for QUIC clients and QUIC servers | ||||||||||||||
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server | |||||||||||||
| Multicast Extension for QUIC | ||||||||||||||
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. | |||||||||||||
| A Multiplane Architecture Proposal for the Quantum Internet | ||||||||||||||
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. | |||||||||||||
| On-time Forwarding with Push-In First-Out (PIFO) queue | ||||||||||||||
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. | |||||||||||||
| No Further Fast Reroute for L3 SRv6 Service SID | ||||||||||||||
|
In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR behaviors for L3 SRv6 Service SIDs in BGP messages. | |||||||||||||
| 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS | ||||||||||||||
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. | |||||||||||||
| Advertisement of Multi-Sourced SAV Rules using BGP Link-State | ||||||||||||||
|
This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rules monitoring and management. | |||||||||||||
| On-time Forwarding with Non-work Conserving Stateless Core Fair Queuing | ||||||||||||||
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [draft-ietf-detnet-dataplane-taxonomy-03]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded between ET and FT in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously compute ET and FT based on metadata received via packet headers. This mechanism is called non-work-preserving stateless fair queuing, which guarantees both E2E latency upper and lower bounds. | |||||||||||||
| New TEAP TLV for Encapsulating DHCPv6 Options | ||||||||||||||
|
This document defines a new Tunneled Extensible Authentication Protocol (TEAP) Type-Length-Value (TLV) to encapsulate DHCPv6 (Dynamic Host Configuration Protocol Version 6) options within TEAP authentication exchanges. This enhancement enables exchange of network configuration parameters after the authentication phase. | |||||||||||||
| Certificate Renewal Recommendations for Enrollment over Secure Transport | ||||||||||||||
|
This document describes an extension to RFC7030, Enrollment over Secure Transport to give an indication to a end-entity device when it should start attempting to renew its certificates. Prior art is that client decides, with a typical recommmendation to start when the remaining lifetime of the certificate is at the 50% point. As typical certificate lifetimes are reduced from years to fractions of a year, the 50% may be far too early, and this document provides a way to give alternate advice. | |||||||||||||
| 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. | |||||||||||||
| In Situ Operations,Administration,and Maintenance (IOAM) Template Option | ||||||||||||||
|
In situ measurement is performed by incorporating performance related information into in-flight data packets. This document specifies a new IOAM Option-Type that has a fixed length and can be updated by transit nodes along the path. It enables lightweight monitoring while maintaining a constant length that is not changed in-flight and is not affected by the number of hops in the network. | |||||||||||||
| Using off-path mechanisms for exposing Time-Variant Routing information | ||||||||||||||
|
Time-Variant Routing (TVR) involves predictable, scheduled changes to network topology elements such as nodes, links, and adjacencies that impact routing behavior over time. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). This document proposes mechanisms for exposing TVR information to both internal and external applications, focusing on off-path solutions that decouple the advertisement of scheduled changes from the routing control plane signaling. | |||||||||||||
| Benchmarking Methodology for Segment Routing | ||||||||||||||
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). It builds upon RFC 2544, RFC 5180, RFC 5695 and RFC 8402. | |||||||||||||
| Implementation Guidance for the PKCS #1 RSA Cryptography Specification | ||||||||||||||
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. | |||||||||||||
| A YANG Data Model for BGP Communities | ||||||||||||||
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. | |||||||||||||
| Peering API | ||||||||||||||
|
We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. | |||||||||||||
| Happy Eyeballs Version 3: Better Connectivity Using Concurrency | ||||||||||||||
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. | |||||||||||||
| Quality of Outcome | ||||||||||||||
|
This document introduces the Quality of Outcome (QoO) framework, a novel approach to network quality assessment designed to align with the needs of application developers, users, and operators. By leveraging the Quality Attenuation metric, QoO provides a unified method for defining and evaluating application-specific network requirements while ensuring actionable insights for network optimization and simple quality scores for end-users. | |||||||||||||
| Multicast Redundant Ingress Router Failover | ||||||||||||||
|
This document analyzes the redundant ingress router failover problem of a multicast domain, and analyzes the possible backup modes and advantages of each mode when deploying multiple ingress devices to forward the same multicast flow in a multicast domain. | |||||||||||||
| Subscription to Notifications in a Distributed Architecture | ||||||||||||||
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. | |||||||||||||
| A Framework for a Network Anomaly Detection Architecture | ||||||||||||||
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. | |||||||||||||
| Lzip Compressed Format and the 'application/lzip' Media Type | ||||||||||||||
|
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. | |||||||||||||
| Advertising SRv6 SIDs for Layer 2 Bundle Member Links in IGP | ||||||||||||||
|
There are deployments where the Layer-3 interface on which IGP operates is a Layer-2 interface bundle. Existing IGP advertisements only support advertising link attributes of the Layer-3 interface. If entities external to IGP wish to control traffic flows on the individual physical links that comprise the Layer-2 interface bundle, link attribute information about the bundle members is advertised by IGP extensions for Layer-2 (L2) bundle. When Segment Routing over IPv6 (SRv6) is used with Layer-2 interface bundle to control traffic flows on the individual member links, the SRv6 SIDs which represent the Layer 2 member links of the L2 bundle needs to be advertised in IGP. This document proposes the IGP extensions to advertise the SRv6 SIDs of the Layer 2 (L2) bundle member links. | |||||||||||||
| IETF Network Slice Deployment Status and Considerations | ||||||||||||||
|
Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided. | |||||||||||||
| A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements | ||||||||||||||
|
PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. | |||||||||||||
| BFD Extension for DetNet Remote Defect Indication (RDI) | ||||||||||||||
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. | |||||||||||||
| Echo Request/Reply for DetNet Capability Discovery | ||||||||||||||
|
This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) | ||||||||||||||
|
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 in Space | ||||||||||||||
|
This document discusses the challenges of running the QUIC transport over deep space links, where delays are in order of minutes and communications are based on scheduled time windows. Using the experience of various testbeds, it provides guidance to implementations to support this use case. This document may apply to other use cases that have similar characteristics, such as IoT in disconnected and distant settings. | |||||||||||||
| Semantic Definition Format (SDF) modeling for Digital Twin | ||||||||||||||
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. | |||||||||||||
| Path Computation Based on Precision Availability Metrics | ||||||||||||||
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. | |||||||||||||
| Path Tracing in SRv6 networks | ||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. | |||||||||||||
| On-Path Telemetry for Active Performance Measurements | ||||||||||||||
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. | |||||||||||||
| A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements | ||||||||||||||
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/yogeshbdeshpande/draft-cca-rats-endorsements. | |||||||||||||
| A YANG Data Model for Resource Performance Monitoring | ||||||||||||||
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. | |||||||||||||
| Schedule for Segment Routing Policy | ||||||||||||||
|
This document defines the Segment Routing (SR) Policy extension for schedule (called SR-Schedule). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR policy schedule including the SR-Schedule definition, acquisition, computation, enforcement, and the handling behaviors on the headend. | |||||||||||||
| Use of Composite ML-DSA in TLS 1.3 | ||||||||||||||
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3. | |||||||||||||
| Architecture of Content-Based Service Router | ||||||||||||||
|
This document first describes an architecture of Content-based Service Router (CSR), which is used to exchange service prefixes and topology information based on distributed routing protocol, and optimize routing based on service prefixes and topology, as one important component of Distributed Micro Service Communication (DMSC) architecture. | |||||||||||||
| IPv6 Network Deployment Monitoring and Analysis | ||||||||||||||
|
This document presents an IPv6 network end-to-end monitoring and analysis system. It describes a standardized end-to-end monitoring and analysis architecture and an indicator system, while also enabling capabilities for end-to-end monitoring data collection and integrated intelligent analysis. This solution has been verified in the operators' network. | |||||||||||||
| SCHClet - Modular Use of the SCHC Framework | ||||||||||||||
|
This document introduces the concept of a SCHClet: a modular sub- function within the SCHC (Static Context Header Compression) framework. Inspired by chiplet architectures in hardware design, a SCHClet encapsulates a specific SCHC function—such as compression, fragmentation, or acknowledgments—as a self-contained unit. This modularization enables tailored implementations that avoid the overhead of deploying a full SCHC stack. By decomposing SCHC functionality into SCHClets, the framework becomes more adaptable, extensible, and suitable for a wider range of network environments—including, but not limited to, constrained networks. A system using SCHClets remains compliant with the SCHC framework and can interoperate with a full SCHC implementation, provided compatible configuration parameters are used. Each SCHClet is defined by the SCHC Profiles and configuration parameters necessary for interoperability. It operates within a single Stratum and a single SCHC Instance. For example, a device may implement only the NoAck fragmentation mode as a standalone SCHClet, potentially with fixed parameters. This modular approach simplifies development, reduces resource demands, and provides a framework for future extensibility of the SCHC architecture. | |||||||||||||
| Composite ML-DSA Signatures for SSH | ||||||||||||||
|
This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. | |||||||||||||
| DHCPv6 Recommended IPv6 Address Option | ||||||||||||||
|
This document defines a new DHCPv6 option for communicating one or more recommended /128 IPv6 address to hosts within an assigned prefix. The Recommended Address option allows DHCPv6 servers to suggest specific IPv6 addresses that hosts should additionally use when configuring addresses within the assigned prefix. | |||||||||||||
| WIMSE Extensions for Trustworthy Workload Identity | ||||||||||||||
|
This document contains a gap analysis that is the output of the Confidential Computing Consortium identifying areas in the IETF WIMSE WG work where the current WIMSE architecture should be extended to accommodate workloads running in Confidential Computing environments. This document contains a high-level outline for these extensions. | |||||||||||||
| Future Requirements of Fine-Grained Privacy for the Network | ||||||||||||||
|
This draft describes some potential new privacy requirements for the future network. We start from the data lifecycle and propose that the privacy needs to be considered during the data is processing. We also introduce some new academic research results. Some use cases are proposed. The goal is to attract IETF working or interest groups in researching to these new requirements in protocol level for the future network. | |||||||||||||
| OAuth2.0 Extention for AI Agent: Authorization on Target | ||||||||||||||
|
In this draft, we address to potential adapt authorization frameworks for the future AI agent. An extension is proposed in the OAuth 2.0 protocol with an optional field *target_id* for granular authorization. It can be seen useful for the future virtual/physical AI agents. By explicitly identifying the target during authorization, the draft aims to support precise permission management and enhance traceability. Serveral risks can be mitigated through the proposed extension, such as potential unauthorized or malicious behavior of AI components in the netowrk, while the compatibility of existing OAuth 2.0 workflows is still maintained. | |||||||||||||
| SRv6 End-to-End DC Frontend and WAN | ||||||||||||||
|
The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through different network domains in a unified and stateless manner, meaning intermediate network devices do not store per-flow information. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). This eliminates the complexities and inefficiencies associated with traditional fragmented network designs. The solution enhances scalability and enables flexible stateless service insertion by unifying the DC and WAN under a single SRv6 domain. | |||||||||||||
| Dynamic Multicast Port Allocation | ||||||||||||||
|
This document proposes a dynamic multicast port allocation mechanism using Segment Routing over IPv6 (SRv6). The solution enables decoupling between the destination port carried in multicast packets sent by the source and the actual receiving port used by receivers. This allows multicast receivers to dynamically allocate unused ports as receiving ports, eliminating the requirement for all receivers to use the same port number. The mechanism defines a new SRv6 function End.MTP for automatic multicast port allocation and supports three operational modes to accommodate different deployment scenarios. | |||||||||||||
| Audio,Video,and Image Metadata extensions for the More Instant Messaging Interoperability (MIMI) Content format | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) content format is a container for rich content, which can reference image, video, and audio files. This document describes metadata for these files to allow for more pleasant rendering. | |||||||||||||
| Guidelines for QUIC Multipath over SCION | ||||||||||||||
|
This document provides informational guidance for using the Multipath Extension for QUIC with the SCION networking technology. SCION is an inter-domain routing protocol that supports path-aware multi-path networking. The multiple paths and their associated path information offered by SCION provide opportunities as well as challenges for combining QUIC-MP with SCION. This document explores various aspects of this combination, such as algorithms for congestion control, RTT estimation, and general application scenarios. In addition, it provides techniques and guidance to maintain the security of QUIC-MP and SCION, and to leverage path-aware multi-path networking with QUIC-MP. | |||||||||||||
| OAuth 2.0 Client ID Prefix | ||||||||||||||
|
This specification defines the concept of a Client Identifier Prefix to enable Authorization Servers and Clients to use more than one mechanism to obtain and validate Client metadata. | |||||||||||||
| HTTP Events Query | ||||||||||||||
|
Events Query is a minimal protocol built on top of HTTP that allows user agents to receive event notifications directly from any resource of interest. The Events Query Protocol (EQP) is predicated on the idea that the most intuitive source for event notifications is the resource itself. | |||||||||||||
| Inter-domain scaling considerations for source address validation (SAV) | ||||||||||||||
|
Source address validation (SAV) covers the general techniques to prevent IP source address spoofing, which is often used in networking attacks. Two primary problem spaces addressed in work on SAV include building the "source of truth" for what IP networks should be permitted to source IP traffic behind a set of network interfaces, and implementing the data plane enforcement for the validation. Implementing data plane enforcement, especially for inter-domain networking for the Internet carried by BGP-4 [RFC 4271] has a number of scaling considerations. One consideration is the potentially large and often asymmetric sizes of the per-interface SAV tables vs. the Forwarding Information Base (FIB). A second consideration is synchronization issues between SAV enforcement mechanisms and the forwarding state for the FIB where a lack of coordination may result in dropped or mis-forwarded traffic. This draft explores these two considerations under the title, "The asymmetric contract, and the broken promise." | |||||||||||||
| A Message Status format for the More Instant Messaging Interoperability (MIMI) content format | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) content format describes a message format for instant messaging. This specification defines a concise, efficient format for communicating status of messages sent using MIMI content. | |||||||||||||
| Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP as described in RFC9604. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. | |||||||||||||
| Digital Emblem (DIEM) Use Cases | ||||||||||||||
|
International law defines a number of emblems, such as the blue helmets of United Nations peacekeeping forces, the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross, as indicative of special protections under the Geneva Conventions. Similar protections attach to journalists who wear "Press" protective emblems on the battlefield, under Article 79 of Protocol I of the Geneva Conventions and Resolution 2222 of the United Nations Security Council. The emblems of national governments and inter-governmental organizations protect diplomatic pouches, couriers, and envoys under the Vienna Convention on Diplomatic Relations. Other marks enjoy protections against mis-use under the Paris Convention, the Madrid Protocol, and the Trade-Related Aspects of Intellectual Property Rights. This document provides an initial summary of problems placing emblems into digital use cases and documents identified requirements from a number of stakeholders with active or potential interests in digital emblems. TODO align abstract and document with the WG charter. | |||||||||||||
| Framework and Automation Levels for AI-Assisted Network Protocol Testing | ||||||||||||||
|
This document presents an AI-assisted framework for automating the testing of network protocol implementations. The proposed framework encompasses essential components such as protocol comprehension, test case generation, automated script and configuration synthesis, and iterative refinement through feedback mechanisms. In addition, the document defines a multi-level model of test automation maturity, ranging from fully manual procedures (Level 0) to fully autonomous and adaptive systems (Level 5), providing a structured approach to evaluating and advancing automation capabilities. Leveraging recent advancements in artificial intelligence, particularly large language models (LLMs), the framework illustrates how AI technologies can be applied to enhance the efficiency, scalability, and consistency of protocol testing. This document serves both as a reference architecture and as a roadmap to guide the evolution of protocol testing practices in light of emerging AI capabilities. | |||||||||||||
| Rights Contributors Provide to IETF Intellectual Property Management Corporation | ||||||||||||||
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo is an update to [RFC5378] and retains the same consistent policies about intellectual property rights in Contributions to the IETF and contains the edits needed to recognize the IETF Intellectual Property Management Corporation (IPMC) as the successor to the IETF Trust. This memo updates [RFC5378]. | |||||||||||||
| Adapting Constrained Devices for Post-Quantum Cryptography | ||||||||||||||
|
This document offers guidance on incorporating Post-Quantum Cryptography (PQC) into resource-constrained devices, including IoT devices and lightweight Hardware Security Modules (HSMs), which operate under tight limitations on compute power, memory, storage, and energy. It highlights how the Root of Trust acts as the foundation for secure operations, enabling features such as seed- based key generation to reduce the need for persistent storage, efficient approaches to managing ephemeral keys, and methods for offloading cryptographic tasks in low-resource environments. Additionally, it examines how PQC affects firmware update mechanisms in such constrained systems. | |||||||||||||
| SRv6 for Redundancy Protection | ||||||||||||||
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability of service transmission in Segment Routing networks. The mechanism uses the "Live-Live" methodology. This document introduces two new SRv6 Segment Endpoint Behavior to provide replication and elimination functions on specific network nodes by leveraging SRv6 Network Programming capabilities. | |||||||||||||
| Distribute SRv6 Locator by DHCP | ||||||||||||||
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through DHCPv6. | |||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) | ||||||||||||||
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture | |||||||||||||
| YANG Data Model for Scheduled Attributes | ||||||||||||||
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. | |||||||||||||
| 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. | |||||||||||||
| WIMSE Workload to Workload Authentication | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. | |||||||||||||
| Framework and Data Model for OTN Network Slicing | ||||||||||||||
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. | |||||||||||||
| A YANG Data Model for WDM Tunnels | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| DTNMA Application Resource Identifier (ARI) | ||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. | |||||||||||||
| DTNMA Application Management Model (AMM) and Data Models | ||||||||||||||
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. | |||||||||||||
| DTNMA Application Data Model (ADM) YANG Syntax | ||||||||||||||
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. | |||||||||||||
| Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND) | ||||||||||||||
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general purpose advertisement mechanism with an initial set of data types able to be advertised by participating nodes in a BPv7 network. | |||||||||||||
| UDP Speed Test Protocol for One-way IP Capacity Measurement | ||||||||||||||
|
This document addresses the problem of protocol support for measuring Network Capacity metrics specified by RFC 9097. The Method of Measurement discussed there requires a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This document defines the UDP Speed Test Protocol for conducting RFC 9097 and other related measurements. | |||||||||||||
| Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs and a crypt-offset to allow for exposing inner flow information for middlebox use. | |||||||||||||
| UDP-based Transport for Configured Subscriptions | ||||||||||||||
|
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. | |||||||||||||
| YANG module file name convention | ||||||||||||||
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and 8407. | |||||||||||||
| MISP taxonomy format | ||||||||||||||
|
This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. | |||||||||||||
| BGP-LS Advertisement of SR Policy Performance Metric | ||||||||||||||
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). | |||||||||||||
| Inter-domain Source Address Validation based on AS relationships | ||||||||||||||
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships named AS Relationship Based Inter-domain Filtering (ARBIF). It primarily describes this method from seven aspects: a brief introduction to the scheme, an overview of the AS relationship classification and acquisition methods, the architecture of the ARBIF system, implementation based on BGP extension, typical use cases, experiments of ARBIF, and considerations for deployability. | |||||||||||||
| BGP SR Policy Extensions for Path Scheduling | ||||||||||||||
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios. This document proposes extensions to BGP SR Policy to deliver the schedule time information of candidate path (segment list) and its associated attributes. | |||||||||||||
| Kademlia-directed ID-based Routing Architecture (KIRA) | ||||||||||||||
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. | |||||||||||||
| Deterministic Networking SRv6 Data Plane | ||||||||||||||
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and optionaly the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. | |||||||||||||
| Deterministic Networking specific SID | ||||||||||||||
|
Replication, Elimination and Ordering functions of the DetNet Architecture require packet sequence information (i.e., sequence number) to provide service protection by the DetNet service sub- layer. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed on packets of DetNet flows to support the specific service protection treatment. | |||||||||||||
| YANG Data Models for fine grain Optical Transport Network | ||||||||||||||
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. | |||||||||||||
| Upper limit values for DNS | ||||||||||||||
|
DNS was designed to have as few hard upper limits as possible to allow for future extensibility. However, the lack of a clear upper limit leads to vulnerabilities, and several attack methods have been reported. This document proposes reasonable upper-limit values for DNS protocols as a Best Current Practice. | |||||||||||||
| BGP Flow Specification Extensions for Scheduling | ||||||||||||||
|
BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time. This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic. | |||||||||||||
| Addition of Extended DNS Errors codes | ||||||||||||||
|
This document is the specification of three new EDE (Extended DNS Errors) codes, for minimal answers, local roots and tailoring based on the client IP address. | |||||||||||||
| 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. | |||||||||||||
| Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications | ||||||||||||||
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes security considerations for short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| Distributed Aggregation Protocol (DAP) Report Binding Extensions | ||||||||||||||
|
Report extensions to the Distributed Aggregation Protocol (DAP) are defined to support new modes of operation for the protocol. This includes a batched submission mode where an intermediary can collect reports prior to settling on an exact task configuration. It also includes more flexibility for modes where a differential privacy mechanism is applied as part of the aggregation process. Report extensions bind the content of reports to the chosen options to ensure that the guarantees that both DAP and differential privacy provide are maintained. | |||||||||||||
| Microservice Communication Resource Scheduling for Distributed AI Model | ||||||||||||||
|
This document describes the architecture of microservice communication resource scheduling for distributed AI model. | |||||||||||||
| WIMSE Credential Exchange | ||||||||||||||
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. | |||||||||||||
| Integrated Sensing and Communications (ISAC) for CATS | ||||||||||||||
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents the ISAC as a typical CATS scenario to facilitate discussions on the potential challenges and requirements. | |||||||||||||
| PQC migration use cases for the telecom network | ||||||||||||||
|
Telecommunications (Telecom) networks are important infrastructure. 3rd Generation Partnership Project (3GPP) provides security specifications for telecom networks, including network devices and user terminals. Meanwhile, the security protocols from IETF widely used in telecom systems. This docuemnt presents some post-quantum risks and assessments that exist in current telecom network, analyzes possible post-quantum migration cases and potential strategy in typical telecom network, the strategy includes the suggestion of related IETF protocols and profiles. | |||||||||||||
| BGP Flowspec Redirects to SR Policy | ||||||||||||||
|
Flowspec, an extension to BGP, enables the dissemination of traffic flow specification rules and can be used to steer traffic into SR Policy. However, existing approaches using Flowspec to direct traffic into a SR Policy have certain drawbacks (for details, refer to section 1). This document difines two new standard actions for the BGP Flowspec V2 protocol (FSv2) [I-D.ietf-idr-flowspec-v2]: Redirect to SR Policy Action and SRv6 SID Action. The former allows traffic to be directed to a designated SR Policy, while the latter allows for the encapsulation of an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action can be used independently or in conjunction with the SRv6 SID Action, depending on the application scenario. Additionally, the SRv6 SID Action can be used together with other actions defined in FSv2, such as Redirect to IPv6. | |||||||||||||
| Remote Attestation with Exported Authenticators | ||||||||||||||
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. | |||||||||||||
| WIMSE Headless JWT Authentication and Authorization | ||||||||||||||
|
In workload-to-service communication, a common pattern is for a workload to present a JSON Web Token (JWT) to a remote endpoint in order to obtain a temporary credential for the service it ultimately needs to access. It is a partial adaptation for workloads of existing flows designed for users. Implementing this pattern combines multiple existing standards from different working groups and standards bodies. Since this pattern is not described in a specification, it leads to variability in interoperability. The purpose of this document is to capture this common workload identity practice as an RFC in order to obtain consistency and promote interoperability in industry. | |||||||||||||
| A SRv6 Traffic Engineering Application for AI Network | ||||||||||||||
|
AI applications require fast processing and responses. Traffic using RoCEv2 has low entropy for ECMP. At the same time, AI elephant flows are predictable. Traffic engineering technology for AI backend networks becomes a possible solution. SRv6 TE can start from the host side, making SRv6 source routing and traffic path control from the host side an optional solution. This document presents a AI network Traffic Engineering (TE) application scenario for handling link faults and traffic congestion issues in data centers, based on Segment Routing over IPv6 (SRv6) and Compressed Segment Identifier (CSID). The application scenario uses SRv6 CSID Network Programming to directly install all forwarding paths on the head-end device. When a data center experiences a link fault or traffic congestion, the head-end device switches the forwarding path to another optimal path for avoiding the location of link fault or traffic congestion, ensuring optimal AI data flow forwarding. | |||||||||||||
| Validating anydata in YANG Library context | ||||||||||||||
|
This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. | |||||||||||||
| MLS Targeted Messages | ||||||||||||||
|
MLS targeted messages allow sending encrypted messages to a specific member of an MLS group. | |||||||||||||
| Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) [RFC5730] extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies. Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. This mapping extends the EPP domain name mapping [RFC5731] to provide additional features required for grace period processing. This document replaces the extension mapping for grace periods described in [RFC3915], rendering that document obsolete. | |||||||||||||
| 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. | |||||||||||||
| BMP Sequence Number,Timestamp and Flags TLVs | ||||||||||||||
|
This document defines a Timestamp TLV that carries a timestamp describing one of multiple possible events related to the BMP message. It also defines a Sequence Number TLV which carries the sequence number of the BMP message for the current BMP session. Finally, this document defines a Flags TLV that replaces the Flags field of the Per-Peer Header, allowing more flags to be allocated in BMP. | |||||||||||||
| YANG Configuration Templates | ||||||||||||||
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing devices to be managed more conveniently and efficiently. | |||||||||||||
| 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. | |||||||||||||
| Realization of SCONE in the 5G Scenario | ||||||||||||||
|
The SCONE protocol provides a scheme for network elements (NEs) to signal the maximally possible throughput limits to end devices, i.e., the flow senders with the assistance from the corresponding flow receivers, for UDP flows transitting thru the NEs. This kind of 'throughput advice' is applied on the per-(UDP)-flow basis. While the advice signaling scheme from NEs inside the traditional public IP network might be challenging, the application of the SCONE scheme to the 5G scenario can be more streamlined and practical. This draft discusses from many perspectives how the SCONE can be realized in the 5G scenario, along with additional advantages that a 5G system might provide to the SCONE. | |||||||||||||
| Kerberos SPAKE with Two-Factor Authentication | ||||||||||||||
|
This document defines a new two-factor authentication mechanism for the Kerberos SPAKE pre-authentication. The mechanism uses the time- based one-time password (TOTP) as a second factor, and combines it with the password factor in a more secure way, which can prevent attackers from both impersonating Kerberos clients and obtaining TGTs' session keys in case of any factor leakage. | |||||||||||||
| Leaf Operation Intents | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol defined in [RFC9420] is an asynchronous secure group messaging protocol, which allows group members to propose their own removal from a group. However, in some cases MLS clients can't reliably use regular Remove or SelfRemove proposals to leave a group because they don't have an up-to-date group state. This document specifies a LeafOperationIntent, which does not need an up-to-date group state but which retains sufficient binding to the client's current state to avoid replay attacks. | |||||||||||||
| OAuth 2.0 for Browser-Based Applications | ||||||||||||||
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. | |||||||||||||
| OAuth Identity and Authorization Chaining Across Domains | ||||||||||||||
|
This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. | |||||||||||||
| Export of GTP-U Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. | |||||||||||||
| PIM Backup Designated Router Procedure | ||||||||||||||
|
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose mechanisms to minimize traffic losses during DR re-election. This document introduces the concept of a Backup Designated Router on a shared LAN and a procedure to perform Delayed DR election. A backup DR on LAN would be useful for faster convergence, whereas a Delayed DR election would be useful for minimizing traffic losses when new routers join a LAN. | |||||||||||||
| Zeroconf Multicast Address Allocation Problem Statement and Requirements | ||||||||||||||
|
This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. | |||||||||||||
| Updates to Dynamic IPv6 Multicast Address Group IDs | ||||||||||||||
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). | |||||||||||||
| Batched Token Issuance Protocol | ||||||||||||||
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. | |||||||||||||
| EAT Measured Component | ||||||||||||||
|
The term "measured component" refers to an object within the attester's target environment whose state can be inspected and, typically, digested. A digest is computed through a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. | |||||||||||||
| 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. | |||||||||||||
| BIER Fast Reroute (BIER-FRR) | ||||||||||||||
|
This document describes BIER Fast Reroute (BIER-FRR) as a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. It enhances the resiliency of BIER by quickly rerouting BIER traffic in the event of a link or node failure. This ensures that multicast traffic continues to reach its intended destinations, thereby minimizing packet loss and service disruption. BIER-FRR is designed to integrate seamlessly with existing BIER operations without requiring per-flow state or additional signaling. The document suggests additional structures for BIER to hold information for backup forwarding entries and to enable them in case of detected failures. BIER-FRR can implement different protection levels, e.g., link protection or node protection, and different protection strategies. Tunnel-based BIER-FRR and LFA-based BIER-FRR are introduced as protection strategies and their implementation with the proposed extensions. A comparison highlights the differences between both approaches. This document serves as an introductory primer to support future, more comprehensive, BIER Fast Reroute analysis and solution development. | |||||||||||||
| External References to Values in CBOR Diagnostic Notation (EDN) | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. | |||||||||||||
| Group Communication for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. | |||||||||||||
| A YANG Data Model for the Alternate Marking Method | ||||||||||||||
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. | |||||||||||||
| On-Path Telemetry YANG Data Model | ||||||||||||||
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. | |||||||||||||
| IGP Unreachable Prefix Announcement | ||||||||||||||
|
Summarization is often used in multi-area or multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. | |||||||||||||
| Extensible YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. | |||||||||||||
| Encrypted Client Hello Deployment Considerations | ||||||||||||||
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. | |||||||||||||
| The Transit Measurement Option | ||||||||||||||
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. | |||||||||||||
| Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) | ||||||||||||||
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. | |||||||||||||
| Post-Quantum Cryptography Recommendations for TLS-based Applications | ||||||||||||||
|
Post-quantum cryptography presents new challenges for applications, end users, and system administrators. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and key supporting protocols such as DNS. | |||||||||||||
| Constrained Application Protocol (CoAP) over Bundle Protocol (BP) | ||||||||||||||
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. | |||||||||||||
| Identity Assertion Authorization Grant | ||||||||||||||
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through a common enterprise identity provider using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. | |||||||||||||
| Operations,Administration and Maintenance (OAM) data collection for service decision-making in Computing-Aware Traffic Steering | ||||||||||||||
|
This document describes the collection of OAM data for services decision-making in Computing-Aware Traffic Steering.In the following section, the main functional components and processes of OAM data collection will be elaborated in detail. | |||||||||||||
| A Top-level Domain for Private Use | ||||||||||||||
|
This document describes the "internal" top-level domain for use in private applications. | |||||||||||||
| Problem Statement with Aggregate Header Limit for IPv6 | ||||||||||||||
|
This document first proposes introduces the concept of "Aggregate header limit for IPv6"(IPv6-AHL) based on RFC8883 to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. | |||||||||||||
| Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks | ||||||||||||||
|
This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, multimedia content production and distributed training. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications. | |||||||||||||
| Requirements for Monitoring RPKI-Related Processes on Routers Using BMP | ||||||||||||||
|
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers on routers, including data retrieval from RPKI caches, RPKI-related policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize router-side monitoring on RPKI within BMP, addressing scalability and interoperability limitations in existing implementations. | |||||||||||||
| Challenges in Transporting Sensing Data with Media Over QUIC | ||||||||||||||
|
This document proposes leveraging Media Over QUIC (MOQ) to address the challenges of transmitting large-scale, real-time sensing data in 6G networks. By building on QUIC's low-latency and multiplexing capabilities, MOQ offers a flexible and efficient transport mechanism tailored to the dynamic and high-throughput requirements of 6G environments. The approach focuses on enabling protocol adaptability across diverse application scenarios such as autonomous driving, smart cities, and industrial IoT, while ensuring efficient data fragmentation, secure and anonymous transmission, and end-to-end QoS awareness. Through information-aware endpoints and optimized data delivery mechanisms, this solution supports scalable, reliable, and intelligent sensing data distribution in next-generation wireless networks. | |||||||||||||
| Post-Quantum Algorithms guidance | ||||||||||||||
|
This document provides general information (such as parameter sizes, security assumptions, and targeted security models) on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. The cryptographic schemes described in this document are among those recommended by major security agencies and/or standardization bodies, and are believed to be secure against Cryptographically Relevant Quantum Computer (CRQC). The goal of this document is to offer a high-level overview of these schemes and their distinguishing features, to help implementers, protocol designers, standards developers, and policymakers in understanding and selecting appropriate post-quantum cryptographic primitives for use in protocols and systems. By aggregating and presenting this information in a unified format, this document aims to facilitate informed decision-making and interoperability during the migration to post-quantum cryptography, and to encourage consistent practices when evaluating and deploying PQC schemes in cryptographic protocols. | |||||||||||||
| JSON Structure: Core | ||||||||||||||
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. | |||||||||||||
| JSON Structure: Import | ||||||||||||||
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. | |||||||||||||
| JSON Structure: Alternate Names and Descriptions | ||||||||||||||
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. | |||||||||||||
| JSON Structure: Symbols,Scientific Units,and Currencies | ||||||||||||||
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. JSON Structure Scientific Units provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. | |||||||||||||
| JSON Structure: Validation Extensions | ||||||||||||||
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. | |||||||||||||
| JSON Structure: Conditional Composition | ||||||||||||||
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. | |||||||||||||
| Securing BPSec Against Arbitrary Packet Dropping | ||||||||||||||
|
In this document we describe Strong Bundle Protocol Audit Mechanism (SBAM), an authentication protocol designed to provide cryptographic auditing services for the Bundle Security protocol. | |||||||||||||
| The Internet Standards Process -- Revision 3 (Updated) | ||||||||||||||
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. | |||||||||||||
| Sticky PIM DR | ||||||||||||||
|
This draft proposes a mechanism to enhance the stability of Protocol Independent Multicast (PIM) Designated Router (DR) election by introducing the concept of a Sticky DR. In traditional PIM operations, the DR role on a LAN may change dynamically in response to router availability or priority changes, leading to potential multicast service disruptions or state reinitialization. The Sticky PIM DR approach aims to retain the previous DR role whenever feasible. By minimizing DR churn, this mechanism improves multicast session continuity, reduces unnecessary Join/Prune message propagation, and enhances operational stability in dense multicast deployments. The draft outlines the procedural extensions to existing PIM DR election, compatibility considerations, and configuration guidelines to support backward interoperability. | |||||||||||||
| Usecase and requirement of deploying PFC and fine-grained flow control | ||||||||||||||
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. | |||||||||||||
| Applicability of MCP for the Network Management | ||||||||||||||
|
The application of MCP in the network management field is meant to develop various rich AI driven network applications, realize intent based networks management automation in the multi-vendor heterogeneous network environment. This document discusses the applicability of MCP to the network management in the IP network that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating MCP into the network management system is also discussed. | |||||||||||||
| 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. | |||||||||||||
| Network Time Protocol Version 5 | ||||||||||||||
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. | |||||||||||||
| Chunked Oblivious HTTP Messages | ||||||||||||||
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. | |||||||||||||
| Extensions Parameter for the RDAP Media Type | ||||||||||||||
|
This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. | |||||||||||||
| RDAP Extensions | ||||||||||||||
|
This document describes and clarifies the usage of extensions in RDAP. | |||||||||||||
| SCITT Reference APIs | ||||||||||||||
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. | |||||||||||||
| Considerations for Benchmarking Network Performance in Containerized Infrastructures | ||||||||||||||
|
Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. | |||||||||||||
| CDNI Cache Control Metadata | ||||||||||||||
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. | |||||||||||||
| CDNI Client Access Control Metadata | ||||||||||||||
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). | |||||||||||||
| Use of ML-KEM in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. | |||||||||||||
| Data Fields for DetNet Enhanced Data Plane | ||||||||||||||
|
The DetNet-specific metadata should be carried in enhanced data plane based on the enhancement requirements. This document proposes the common DetNet data fields and option types such as Aggregation Option and Deterministic Latency Option. The common DetNet Data-Fields can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. | |||||||||||||
| Recommendations for using Multiple IP Addresses in Benchmarking Tests | ||||||||||||||
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. | |||||||||||||
| CoAP in Space | ||||||||||||||
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. | |||||||||||||
| IPv6 Extended Fragment Header (EFH) | ||||||||||||||
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. 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. | |||||||||||||
| Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture | ||||||||||||||
|
The document [I-D.draft-ietf-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. | |||||||||||||
| Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP | ||||||||||||||
|
This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. | |||||||||||||
| A YANG Data Model for Service Path Computation | ||||||||||||||
|
This document defines a YANG data model for client signal service's path computation and path management. | |||||||||||||
| SR based Loop-free implementation | ||||||||||||||
|
Microloops are transient packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss, jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. | |||||||||||||
| Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism | ||||||||||||||
|
The Internet Control Message Protocol (ICMP) plays a crucial role in network diagnostics and error reporting. However, it is a challenge to verify the legitimacy of a received ICMP error message, particularly when the ICMP error message is embedded with stateless protocol data. As a result, adversaries can forge ICMP error messages, leading to potential exploitation and off-path attacks. This document explores solutions to this problem by first presenting a straightforward but flawed stateful challenge-response mechanism. It explains how this "strawman" approach, while preventing simple spoofing, introduces a severe vulnerability to state-exhaustion Denial-of-Service (DoS) attacks. Building on this analysis, the document then proposes a robust, stateless challenge-response mechanism inspired by TCP SYN-Cookies. This final proposal eliminates the need to store per-challenge state by computationally generating challenges. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state- exhaustion DoS attacks, thus significantly improving the robustness of ICMP. Additionally, it discusses security and deployment considerations to ensure its practical implementation. | |||||||||||||
| Additional CATS requirements consideration for Service Segmentation-related use cases | ||||||||||||||
|
This document discusses possible additional CATS requirements when considering service segmentation in related CATS use cases such as AR-VR and Distributed AI Inference | |||||||||||||
| Certificate Transparency Pages Extension | ||||||||||||||
|
This document specifies an extension to RFC 6962 Certificate Transparency (CT) logs that enables efficient caching and batch retrieval through page-based access patterns. The extension introduces a binary format that eliminates base64 encoding overhead and certificate chain duplication while maintaining full backward compatibility with existing RFC 6962 implementations. | |||||||||||||
| Competitive Mode Enhancement for Delay-Based Congestion Control Algorithms | ||||||||||||||
|
This document proposes introducing a "Competitive Mode" into delay- based congestion control algorithms to improve their competitiveness and fairness during coexistence scenarios. | |||||||||||||
| OAuth SPIFFE Client Authentication | ||||||||||||||
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. | |||||||||||||
| Digital Identity Management for AI Agent Communication Protocols | ||||||||||||||
|
AI agents are rapidly and massively transitioning from cutting-edge technology into real life. The AI agent communication protocol will establishing a critical means to connect agents with different users, tools, and other agents. Among all the features of AI agent communication protocol, digital identity is one of the most important components. Developing a cross-industry, universal, flexible, interoperable, and secure AI agent digital identity protocol is the foundation for achieving communication between agents and other entities in future network. | |||||||||||||
| ECH Considered Harmful | ||||||||||||||
|
Encrypted Client Hello is designed to enhance personal privacy, in particular obstructing the ability of communications service providers (but not Over The Top service providers) to map packet flows to applications. While mostly ineffective in attaining this goal, it does severely hamper network-based detection of malicious flows, thus exposing end-users to various security risks that were previously avoidable. | |||||||||||||
| SSH File Transfer Protocol | ||||||||||||||
|
The SSH File Transfer Protocol provides secure file transfer functionality over any secure and reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. | |||||||||||||
| Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and Encapsulating Security Payload (ESP) Protocols | ||||||||||||||
|
This document specifies the use of AES-GCM-SIV in the Internet Key Exchange Protocol version 2 (IKEv2) and the Encapsulating Security Payload (ESP) protocols. This document also adds AES-GCM-SIV to the IANA IKEv2 registry for "Transform Type 1 - Encryption Algorithm Transform IDs." AES-GCM-SIV is a nonce misuse-resistant authenticated encryption with associated data (AEAD) algorithm based on AES-GCM. | |||||||||||||
| Enhancements to the YANG Language for Capturing Subtree Replacements | ||||||||||||||
|
As YANG data models evolve over time, model nodes are often deprecated or made obsolete. Current practices for documenting replacement paths for these nodes rely on unstructured external documents, making it difficult to programmatically identify and migrate to replacement nodes. This document proposes a YANG extension mechanism that embeds replacement path information directly within YANG models, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. | |||||||||||||
| Securing QUIC with MLS | ||||||||||||||
|
This document describes how Messaging Layer Security (MLS) can be used in place of Transport Layer Security (TLS) to secure QUIC. | |||||||||||||
| Rich OAuth Error Responses | ||||||||||||||
|
Define an error-handling protocol extension for the OAuth 2.0 token endpoint that allows the authorization server or resource server to specify an extra parameter on error responses that should be passed through to follow-up authorization requests. | |||||||||||||
| Deployment and Use of the Domain Name System(DNS) in Deep Space | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. | |||||||||||||
| Network Digital Twin based Architecture for AI driven Network Operations | ||||||||||||||
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Integrating a Network Digital Twin into network management together with AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Network Digital Twin and AI which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together. It provides a cookbook of existing technologies to satisfy the architecture and realize intent-based networking to meet the needs of the network service. | |||||||||||||
| BGP Extensions to Enable BGP FlowSpec Based IFIT | ||||||||||||||
|
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow- oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. So IFIT behavior can be applied to the specified flow automatically. | |||||||||||||
| Post-Quantum Cryptography for Engineers | ||||||||||||||
|
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. | |||||||||||||
| Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses | ||||||||||||||
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. | |||||||||||||