| |
|
| |
| | 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 |
| |
| | draft-ietf-intarea-rfc8335bis-01.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Bill Fenner, Ron Bonica, Reji Thomas, Jen Linkova, Chris Lenart, Mohamed Boucadair |
| | Working Group: |
Internet Area Working Group (intarea) |
|
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. |
| | 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 |
| |
| | draft-idr-bgp-route-refresh-options-06.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda, Krishnaswamy Ananthamurthy |
| | Working Group: |
Individual Submissions (none) |
|
[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 |
| |
| | draft-venhoek-nts-pool-03.txt |
| | Date: |
21/07/2025 |
| | Authors: |
David Venhoek, Folkert de Vries, Marc Schoolderman |
| | Working Group: |
Individual Submissions (none) |
|
The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. |
| | 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 |
| |
| | draft-gundavelli-radepcs-01.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Sri Gundavelli, Subir Das, Mark Grayson, Martin Dolly, An Nguyen |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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 |
| |
| | draft-pham-cfrg-hiae-02.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes HiAE, a high-throughput authenticated encryption algorithm designed for next-generation wireless systems (6G) and high-speed data transmission applications. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/hiae-aead/draft-pham-hiae. |
| | The IPv6 Multicast Routing Headers (MRH) |
| |
| | draft-eckert-pim-mrh-01.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Toerless Eckert, Yisong Liu, Yongqing Zhu, Changwang Lin |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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) |
| |
| | draft-ietf-teas-nrp-yang-04.txt |
| | Date: |
21/07/2025 |
| | Authors: |
Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
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. |
| | 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. |
| | 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]) |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Conveying Transceiver-Related Information within RSVP-TE Signaling |
| |
| | draft-ietf-ccamp-tsvmode-signaling-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Julien Meuric, Esther Le Rouzic, Gabriele Galimberti, Sergio Belotti, Dieter Beller |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | A Mechanism for X.509 Certificate Discovery |
| |
| | draft-ietf-lamps-certdiscovery-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
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. |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-23.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
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) |
| |
| | draft-ietf-lisp-rfc8060bis-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Alvaro Retana, Dino Farinacci, David Meyer, Job Snijders |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. |
| | 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. |
| | 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. |
| | Low Overhead Media Container |
| |
| | draft-ietf-moq-loc-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Mo Zanaty, Suhas Nandakumar, Peter Thatcher |
| | Working Group: |
Media Over QUIC (moq) |
|
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 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. |
| | 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". |
| | NTRU Key Encapsulation |
| |
| | draft-fluhrer-cfrg-ntru-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Scott Fluhrer, Michael Prorock, Sofia Celi, John Gray, Xagawa Keita, Haruhisa Kosuge |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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 |
| |
| | draft-oh-nmrg-ai-adp-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Oh Seokbeom, Yong-Geun Hong, Joo-Sang Youn, Hyunjeong Lee, Seung-Woo Hong, Hyun-Kook Kahng |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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 |
| |
| | draft-piraux-tcp-ao-tls-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen |
| | Working Group: |
Individual Submissions (none) |
|
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). |
| | 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 |
| |
| | draft-lenders-core-dnr-06.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
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). |
| | 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. |
| | 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 |
| |
| | draft-welzl-iccrg-pacing-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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 |
| |
| | draft-ygb-ivy-passive-network-inventory-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Chaode Yu, Aihua Guo, Italo Busi, Mohammad Boroon, Sergio Belotti, tom van caenegem, Swaminathan S., Swaminathan B., Nigel Davis, Mauro Tilocca, Brad Peters, Bin Yoon, liuyucong, Yang Zhao, Avinash Sakalabhaktula |
| | Working Group: |
Individual Submissions (none) |
|
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]. |
| | 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. |
| | 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. |
| | 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. |
| | 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 |
| |
| | draft-kompella-teas-mpte-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Kireeti Kompella, Luay Jalil, Mazen Khaddam, Andy Smith |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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 |
| |
| | draft-various-eimpact-arch-considerations-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Michael Welzl, Emile Stephan, Eve Schooler, Sebastien Rumley, Ali Rezaki, Jukka Manner, Carlos Pignataro, Marisol Amador, Jan Lindblad, Suresh Krishnan, Ari Keranen, Hesham ElBakoury, Luis Contreras, Alexander Clemm, Jari Arkko |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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 |
| |
| | draft-rats-runtime-tpr-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Ioannis Krontiris, Thanassis Giannetsos, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Static Context Header Compression Over 5G |
| |
| | draft-mokdad-schc-into-5g-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Amina MOKDAD, Laurent Toutain, Xavier Lagrange, Alexander Pelov |
| | Working Group: |
Individual Submissions (none) |
|
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). |
| | 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. |
| | 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. |
| | 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. |
| | Delay-Tolerant Networking Architecture |
| |
| | draft-cerf-dtn-4838bis-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Vinton Cerf, Scott Burleigh, Robert Durst, Kevin Fall, Keith Scott, Jordan Torgerson, Howard Weiss |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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 |
| |
| | draft-vcon-consent-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Thomas McCarthy-Howe, Steve Lasker |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Common Ancestor Objective Function and Parent Set DAG Metric Container Extension |
| |
| | draft-ietf-roll-nsa-extension-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thubert |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | Peering API |
| |
| | draft-ietf-grow-peering-api-01.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Carlos Aguado, Matt Griswold, Jenny Ramseyer, Arturo Servin, Tom Strickx, Q Misell |
| | Working Group: |
Global Routing Operations (grow) |
|
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. |
| | 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. |
| | 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) |
| |
| | draft-huang-detnet-rdi-03.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Hongyi Huang, Li Zhang, Tianran Zhou, Jing Gao |
| | Working Group: |
Individual Submissions (none) |
|
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) |
| |
| | draft-dong-pce-pcep-nrp-04.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | Path Tracing in SRv6 networks |
| |
| | draft-filsfils-ippm-path-tracing-04.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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 |
| |
| | draft-yu-ccamp-resource-pm-yang-03.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, Mingshuang Jin |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | Digital Emblem (DIEM) Use Cases |
| |
| | draft-diem-fainchtein-use-cases-00.txt |
| | Date: |
04/07/2025 |
| | Authors: |
Rahel Fainchtein, Casey Deccio, Brian Haberman, Bill Woodcock, Allison Mankin, Alex Rosenberg |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |