| |
|
| |
| | Meticulous Keyed ISAAC for BFD Optimized Authentication |
| |
|
This document describes a new BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the the "Up" state. |
| | Framework and Data Model for OTN Network Slicing |
| |
| | draft-ietf-ccamp-yang-otn-slicing-09.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. |
| | A YANG Data Model for WDM Tunnels |
| |
| | draft-ietf-ccamp-wdm-tunnel-yang-05.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | DTNMA Application Resource Identifier (ARI) |
| |
| | draft-ietf-dtn-ari-06.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Edward Birrane, Emery Annis, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. |
| | DTNMA Application Management Model (AMM) and Data Models |
| |
| | draft-ietf-dtn-amm-05.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. |
| | DTNMA Application Data Model (ADM) YANG Syntax |
| |
| | draft-ietf-dtn-adm-yang-04.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. |
| | Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND) |
| |
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general purpose advertisement mechanism with an initial set of data types able to be advertised by participating nodes in a BPv7 network. |
| | UDP Speed Test Protocol for One-way IP Capacity Measurement |
| |
|
This document addresses the problem of protocol support for measuring Network Capacity metrics specified by RFC 9097. The Method of Measurement discussed there requires a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This document defines the UDP Speed Test Protocol for conducting RFC 9097 and other related measurements. |
| | Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-01.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Steffen Klassert, Antony Antony, Christian Hopps |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs and a crypt-offset to allow for exposing inner flow information for middlebox use. |
| | 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. |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-22.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Alex Feng, Pierre Francois, Tianran Zhou, Thomas Graf, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | Augmented-by Addition to the YANG Library |
| |
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| | YANG module file name convention |
| |
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and 8407. |
| | MISP taxonomy format |
| |
|
This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. |
| | BGP-LS Advertisement of SR Policy Performance Metric |
| |
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| | Inter-domain Source Address Validation based on AS relationships |
| |
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships named AS Relationship Based Inter-domain Filtering (ARBIF). It primarily describes this method from seven aspects: a brief introduction to the scheme, an overview of the AS relationship classification and acquisition methods, the architecture of the ARBIF system, implementation based on BGP extension, typical use cases, experiments of ARBIF, and considerations for deployability. |
| | Kademlia-directed ID-based Routing Architecture (KIRA) |
| |
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. |
| | Deterministic Networking SRv6 Data Plane |
| |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and optionaly the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. |
| | Deterministic Networking specific SID |
| |
|
Replication, Elimination and Ordering functions of the DetNet Architecture require packet sequence information (i.e., sequence number) to provide service protection by the DetNet service sub- layer. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed on packets of DetNet flows to support the specific service protection treatment. |
| | YANG Data Models for fine grain Optical Transport Network |
| |
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. |
| | Addition of Extended DNS Errors codes |
| |
|
This document is the specification of three new EDE (Extended DNS Errors) codes, for minimal answers, local roots and tailoring based on the client IP address. |
| | Use of SHA-3 in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec |
| |
|
This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. |
| | Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications |
| |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes security considerations for short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | Microservice Communication Resource Scheduling for Distributed AI Model |
| |
|
This document describes the architecture of microservice communication resource scheduling for distributed AI model. |
| | WIMSE Credential Exchange |
| |
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. |
| | Integrated Sensing and Communications (ISAC) for CATS |
| |
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents the ISAC as a typical CATS scenario to facilitate discussions on the potential challenges and requirements. |
| | BGP Flowspec Redirects to SR Policy |
| |
|
Flowspec, an extension to BGP, enables the dissemination of traffic flow specification rules and can be used to steer traffic into SR Policy. However, existing approaches using Flowspec to direct traffic into a SR Policy have certain drawbacks (for details, refer to section 1). This document difines two new standard actions for the BGP Flowspec V2 protocol (FSv2) [I-D.ietf-idr-flowspec-v2]: Redirect to SR Policy Action and SRv6 SID Action. The former allows traffic to be directed to a designated SR Policy, while the latter allows for the encapsulation of an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action can be used independently or in conjunction with the SRv6 SID Action, depending on the application scenario. Additionally, the SRv6 SID Action can be used together with other actions defined in FSv2, such as Redirect to IPv6. |
| | Remote Attestation with Exported Authenticators |
| |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. |
| | WIMSE Headless JWT Authentication and Authorization |
| |
|
In workload-to-service communication, a common pattern is for a workload to present a JSON Web Token (JWT) to a remote endpoint in order to obtain a temporary credential for the service it ultimately needs to access. It is a partial adaptation for workloads of existing flows designed for users. Implementing this pattern combines multiple existing standards from different working groups and standards bodies. Since this pattern is not described in a specification, it leads to variability in interoperability. The purpose of this document is to capture this common workload identity practice as an RFC in order to obtain consistency and promote interoperability in industry. |
| | A SRv6 Traffic Engineering Application for AI Network |
| |
|
AI applications require fast processing and responses. Traffic using RoCEv2 has low entropy for ECMP. At the same time, AI elephant flows are predictable. Traffic engineering technology for AI backend networks becomes a possible solution. SRv6 TE can start from the host side, making SRv6 source routing and traffic path control from the host side an optional solution. This document presents a AI network Traffic Engineering (TE) application scenario for handling link faults and traffic congestion issues in data centers, based on Segment Routing over IPv6 (SRv6) and Compressed Segment Identifier (CSID). The application scenario uses SRv6 CSID Network Programming to directly install all forwarding paths on the head-end device. When a data center experiences a link fault or traffic congestion, the head-end device switches the forwarding path to another optimal path for avoiding the location of link fault or traffic congestion, ensuring optimal AI data flow forwarding. |
| | Validating anydata in YANG Library context |
| |
|
This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. |
| | MLS Targeted Messages |
| |
|
MLS targeted messages allow sending encrypted messages to a specific member of an MLS group. |
| | Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) [RFC5730] extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies. Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. This mapping extends the EPP domain name mapping [RFC5731] to provide additional features required for grace period processing. This document replaces the extension mapping for grace periods described in [RFC3915], rendering that document obsolete. |
| | Workload Identifier |
| |
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. |
| | BMP Sequence Number,Timestamp and Flags TLVs |
| |
|
This document defines a Timestamp TLV that carries a timestamp describing one of multiple possible events related to the BMP message. It also defines a Sequence Number TLV which carries the sequence number of the BMP message for the current BMP session. Finally, this document defines a Flags TLV that replaces the Flags field of the Per-Peer Header, allowing more flags to be allocated in BMP. |
| | YANG Configuration Templates |
| |
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing devices to be managed more conveniently and efficiently. |
| | DNS-based Service Discovery for Computing-Aware Traffic Steering (CATS) |
| |
|
This document specifies how DNS-based Service Discovery (DNS-SD) can be used as a discovery and resolving method for mapping service identifiers to specific addresses within the CATS framework. It details extensions to DNS-SD to support CATS-specific service discovery requirements and describes how the discovery mechanism integrates with other components of the CATS architecture to enable compuating-aware traffic steering. |
| | 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. |
| | Realization of SCONE in the 5G Scenario |
| |
|
The SCONE protocol provides a scheme for network elements (NEs) to signal the maximally possible throughput limits to end devices, i.e., the flow senders with the assistance from the corresponding flow receivers, for UDP flows transitting thru the NEs. This kind of 'throughput advice' is applied on the per-(UDP)-flow basis. While the advice signaling scheme from NEs inside the traditional public IP network might be challenging, the application of the SCONE scheme to the 5G scenario can be more streamlined and practical. This draft discusses from many perspectives how the SCONE can be realized in the 5G scenario, along with additional advantages that a 5G system might provide to the SCONE. |
| | OAuth 2.0 for Browser-Based Applications |
| |
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-05.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
| | draft-ietf-opsawg-ipfix-gtpu-06.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Vyasraj Satyanarayana, Cristian Staicu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT |
| |
| | draft-ietf-pce-pcep-ifit-07.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola |
| | Working Group: |
Path Computation Element (pce) |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. |
| | PIM Backup Designated Router Procedure |
| |
| | draft-ietf-pim-bdr-03.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Mankamana Mishra, Anuj Budhiraja, Joya Neema, Imed Romdhani, Gyan Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose mechanisms to minimize traffic losses during DR re-election. This document introduces the concept of a Backup Designated Router on a shared LAN and a procedure to perform Delayed DR election. A backup DR on LAN would be useful for faster convergence, whereas a Delayed DR election would be useful for minimizing traffic losses when new routers join a LAN. |
| | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
|
This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses |
| |
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-16.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
The Remote Attestation Procedures architecture (RFC 9334) defines several types of conceptual messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. These messages can appear in different formats and be transported via various protocols. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. |
| | EAT Measured Component |
| |
|
The term "measured component" refers to an object within the attester's target environment whose state can be inspected and, typically, digested. A digest is computed through a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
| | draft-ietf-roll-enrollment-priority-13.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a Routing Protocol for Low- Power and Lossy Networks (RPL) Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| | Cursor-based Pagination of SCIM Resources |
| |
|
This document updates RFC7643 and RFC7644 by defining additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM service providers that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. |
| | Cryptographic Algorithm Recommendations for Software Updates of Internet of Things Devices |
| |
| | draft-ietf-suit-mti-19.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This document specifies cryptographic algorithm profiles to be used with the Software Updates for Internet of Things (SUIT) manifest. These profiles define mandatory-to-implement algorithms to ensure interoperability. |
| | 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. |
| |
|
| |
| | Generic Address Assignment Option for 6LoWPAN Neighbor Discovery |
| |
| | draft-ietf-6lo-nd-gaao-05.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Luigi Iannone, David Lou, Adnan Rashid |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. |
| | BIER Fast Reroute (BIER-FRR) |
| |
| | draft-ietf-bier-frr-10.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes BIER Fast Reroute (BIER-FRR) as a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. It enhances the resiliency of BIER by quickly rerouting BIER traffic in the event of a link or node failure. This ensures that multicast traffic continues to reach its intended destinations, thereby minimizing packet loss and service disruption. BIER-FRR is designed to integrate seamlessly with existing BIER operations without requiring per-flow state or additional signaling. The document suggests additional structures for BIER to hold information for backup forwarding entries and to enable them in case of detected failures. BIER-FRR can implement different protection levels, e.g., link protection or node protection, and different protection strategies. Tunnel-based BIER-FRR and LFA-based BIER-FRR are introduced as protection strategies and their implementation with the proposed extensions. A comparison highlights the differences between both approaches. This document serves as an introductory primer to support future, more comprehensive, BIER Fast Reroute analysis and solution development. |
| | External References to Values in CBOR Diagnostic Notation (EDN) |
| |
| | draft-ietf-cbor-edn-e-ref-02.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. |
| | Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| | A YANG Data Model for the Alternate Marking Method |
| |
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. |
| | On-Path Telemetry YANG Data Model |
| |
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. |
| | IGP Unreachable Prefix Announcement |
| |
|
Summarization is often used in multi-area or multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. |
| | IMAP UIDBATCHES Extension |
| |
|
The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve UID ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable. |
| | Transaction ID Mechanism for NETCONF |
| |
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. |
| | Extensible YANG Model for Network Telemetry Messages |
| |
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. |
| | Encrypted Client Hello Deployment Considerations |
| |
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. |
| | The Transit Measurement Option |
| |
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. |
| | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| | draft-sajassi-bess-rfc8317bis-04.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger |
| | Working Group: |
Individual Submissions (none) |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. |
| | Post-Quantum Cryptography Recommendations for TLS-based Applications |
| |
|
Post-quantum cryptography presents new challenges for applications, end users, and system administrators. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and key supporting protocols such as DNS. |
| | Constrained Application Protocol (CoAP) over Bundle Protocol (BP) |
| |
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. |
| | Identity Assertion Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through a common enterprise identity provider using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| | Operations,Administration and Maintenance (OAM) data collection for service decision-making in Computing-Aware Traffic Steering |
| |
|
This document describes the collection of OAM data for services decision-making in Computing-Aware Traffic Steering.In the following section, the main functional components and processes of OAM data collection will be elaborated in detail. |
| | A Top-level Domain for Private Use |
| |
|
This document describes the "internal" top-level domain for use in private applications. |
| | 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. |
| | Problem Statement with Aggregate Header Limit for IPv6 |
| |
|
This document first proposes introduces the concept of "Aggregate header limit for IPv6"(IPv6-AHL) based on RFC8883 to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. |
| | Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, multimedia content production and distributed training. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications. |
| | Requirements for Monitoring RPKI-Related Processes on Routers Using BMP |
| |
|
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers on routers, including data retrieval from RPKI caches, RPKI-related policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize router-side monitoring on RPKI within BMP, addressing scalability and interoperability limitations in existing implementations. |
| | Challenges in Transporting Sensing Data with Media Over QUIC |
| |
|
This document proposes leveraging Media Over QUIC (MOQ) to address the challenges of transmitting large-scale, real-time sensing data in 6G networks. By building on QUIC's low-latency and multiplexing capabilities, MOQ offers a flexible and efficient transport mechanism tailored to the dynamic and high-throughput requirements of 6G environments. The approach focuses on enabling protocol adaptability across diverse application scenarios such as autonomous driving, smart cities, and industrial IoT, while ensuring efficient data fragmentation, secure and anonymous transmission, and end-to-end QoS awareness. Through information-aware endpoints and optimized data delivery mechanisms, this solution supports scalable, reliable, and intelligent sensing data distribution in next-generation wireless networks. |
| | Post-Quantum Algorithms guidance |
| |
|
This document provides general information (such as parameter sizes, security assumptions, and targeted security models) on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. The cryptographic schemes described in this document are among those recommended by major security agencies and/or standardization bodies, and are believed to be secure against Cryptographically Relevant Quantum Computer (CRQC). The goal of this document is to offer a high-level overview of these schemes and their distinguishing features, to help implementers, protocol designers, standards developers, and policymakers in understanding and selecting appropriate post-quantum cryptographic primitives for use in protocols and systems. By aggregating and presenting this information in a unified format, this document aims to facilitate informed decision-making and interoperability during the migration to post-quantum cryptography, and to encourage consistent practices when evaluating and deploying PQC schemes in cryptographic protocols. |
| | RESTful Provisioning Protocol (RPP) |
| |
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. |
| | JSON Structure: Core |
| |
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. |
| | JSON Structure: Import |
| |
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. |
| | JSON Structure: Alternate Names and Descriptions |
| |
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. |
| | JSON Structure: Symbols,Scientific Units,and Currencies |
| |
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. JSON Structure Scientific Units provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. |
| | JSON Structure: Validation Extensions |
| |
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. |
| | JSON Structure: Conditional Composition |
| |
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. |
| | RTP Payload Format for Avatar |
| |
|
This memo outlines RTP payload formats for the MPEG-I Avatar data. A Avatar Stream format (ASF) is composed of Avatar animation unit (AAU) including a AAU header and zero or more AAU packets. The RTP Payload header format allows for packetization of a AAU unit in an RTP packet payload as well as fragmentation of a AAU into multiple RTP packets. |
| | Securing BPSec Against Arbitrary Packet Dropping |
| |
| | draft-tian-dtn-sbam-00.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Benjamin Dowling, Britta Hale, Xisen Tian, Bhagya Wimalasiri |
| | Working Group: |
Individual Submissions (none) |
|
In this document we describe Strong Bundle Protocol Audit Mechanism (SBAM), an authentication protocol designed to provide cryptographic auditing services for the Bundle Security protocol. |
| | The Internet Standards Process -- Revision 3 (Updated) |
| |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
| | Sticky PIM DR |
| |
|
This draft proposes a mechanism to enhance the stability of Protocol Independent Multicast (PIM) Designated Router (DR) election by introducing the concept of a Sticky DR. In traditional PIM operations, the DR role on a LAN may change dynamically in response to router availability or priority changes, leading to potential multicast service disruptions or state reinitialization. The Sticky PIM DR approach aims to retain the previous DR role whenever feasible. By minimizing DR churn, this mechanism improves multicast session continuity, reduces unnecessary Join/Prune message propagation, and enhances operational stability in dense multicast deployments. The draft outlines the procedural extensions to existing PIM DR election, compatibility considerations, and configuration guidelines to support backward interoperability. |
| | Usecase and requirement of deploying PFC and fine-grained flow control |
| |
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. |
| | Applicability of MCP for the Network Management |
| |
| | draft-yang-nmrg-mcp-nm-00.txt |
| | Date: |
02/07/2025 |
| | Authors: |
YUANYUANYANG, Qin WU, Diego Lopez, Nathalie Moreno, Lionel Tailhardat |
| | Working Group: |
Individual Submissions (none) |
|
The application of MCP in the network management field is meant to develop various rich AI driven network applications, realize intent based networks management automation in the multi-vendor heterogeneous network environment. This document discusses the applicability of MCP to the network management in the IP network that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating MCP into the network management system is also discussed. |
| | PIM Reverse Path Forwarding (RPF) Vetor Conflict Resolution |
| |
|
[RFC7891] Section 7 defines the handling principles for PIM Join attributes with same type of RFF Vector and Explicit RFP Vector, but with different contents are received. However, it does not address scenarios where one downstream router includes a RFF Vector in its message while another does not. This leaves the handling of such conflicts unspecified. This document supplements the existing specifications by defining the processing rules for this specific conflict scenario. |
| | Network Time Protocol Version 5 |
| |
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. |
| | Chunked Oblivious HTTP Messages |
| |
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. |
| | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay in the OAM transit and decapsulating nodes. |
| | Guidelines for Characterizing "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. |
| | Extensions Parameter for the RDAP Media Type |
| |
|
This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | SCITT Reference APIs |
| |
| | draft-ietf-scitt-scrapi-05.txt |
| | Date: |
02/07/2025 |
| | Authors: |
Henk Birkholz, Jon Geater |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. |
| |
|
| |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-08.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices, as well as a CBOR-based publish-subscribe interface for streaming data. The described interfaces are extensible. The specification also defines a protocol mapping function to to map this interface to commonly used non-IP protocols. |
| | Considerations for Benchmarking Network Performance in Containerized Infrastructures |
| |
|
Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. |
| | CDNI Cache Control Metadata |
| |
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. |
| | CDNI Client Access Control Metadata |
| |
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). |
| | Use of ML-KEM in the Cryptographic Message Syntax (CMS) |
| |
| | draft-ietf-lamps-cms-kyber-11.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Julien Prat, Mike Ounsworth, Daniel Van Geest |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-13.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an alternative experimental approach for the application of the Alternate-Marking Method to SRv6. It uses a new TLV in the Segment Routing Header (SRH) with experimental code points, and thus participation in this experiment should be between coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343 and the scope of the experiment is to determine whether those are significant and attractive to the community. This protocol extension has been developed outside the IETF as an alternative to the IETF’s standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. Researchers are invited to submit their evaluations of this work to the RFC Editor for consideration as independent submissions or to the IETF SPRING working group as Internet-Drafts. |
| | Data Fields for DetNet Enhanced Data Plane |
| |
|
The DetNet-specific metadata should be carried in enhanced data plane based on the enhancement requirements. This document proposes the common DetNet data fields and option types such as Aggregation Option and Deterministic Latency Option. The common DetNet Data-Fields can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. |
| | Recommendations for using Multiple IP Addresses in Benchmarking Tests |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. |
| | CoAP in Space |
| |
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. |
| | Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
| |
|
The document [I-D.draft-ietf-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. |
| | Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP |
| |
| | draft-wang-idr-bgp-nof-nlri-03.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Ruixue Wang, Changwang Lin, Rui Zhuang, Fengwei Qin, Qi Zhang, wangwenxuan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. |
| | A YANG Data Model for Resource Performance Monitoring |
| |
| | draft-yu-ccamp-resource-pm-yang-02.txt |
| | Date: |
01/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. |
| | A YANG Data Model for Service Path Computation |
| |
|
This document defines a YANG data model for client signal service's path computation and path management. |
| | SR based Loop-free implementation |
| |
|
Microloops are transient packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss, jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol (ICMP) plays a crucial role in network diagnostics and error reporting. However, it is a challenge to verify the legitimacy of a received ICMP error message, particularly when the ICMP error message is embedded with stateless protocol data. As a result, adversaries can forge ICMP error messages, leading to potential exploitation and off-path attacks. This document explores solutions to this problem by first presenting a straightforward but flawed stateful challenge-response mechanism. It explains how this "strawman" approach, while preventing simple spoofing, introduces a severe vulnerability to state-exhaustion Denial-of-Service (DoS) attacks. Building on this analysis, the document then proposes a robust, stateless challenge-response mechanism inspired by TCP SYN-Cookies. This final proposal eliminates the need to store per-challenge state by computationally generating challenges. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state- exhaustion DoS attacks, thus significantly improving the robustness of ICMP. Additionally, it discusses security and deployment considerations to ensure its practical implementation. |
| | Additional CATS requirements consideration for Service Segmentation-related use cases |
| |
|
This document discusses possible additional CATS requirements when considering service segmentation in related CATS use cases such as AR-VR and Distributed AI Inference |
| | Certificate Transparency Pages Extension |
| |
|
This document specifies an extension to RFC 6962 Certificate Transparency (CT) logs that enables efficient caching and batch retrieval through page-based access patterns. The extension introduces a binary format that eliminates base64 encoding overhead and certificate chain duplication while maintaining full backward compatibility with existing RFC 6962 implementations. |
| | Competitive Mode Enhancement for Delay-Based Congestion Control Algorithms |
| |
|
This document proposes introducing a "Competitive Mode" into delay- based congestion control algorithms to improve their competitiveness and fairness during coexistence scenarios. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| | Digital Identity Management for AI Agent Communication Protocols |
| |
|
AI agents are rapidly and massively transitioning from cutting-edge technology into real life. The AI agent communication protocol will establishing a critical means to connect agents with different users, tools, and other agents. Among all the features of AI agent communication protocol, digital identity is one of the most important components. Developing a cross-industry, universal, flexible, interoperable, and secure AI agent digital identity protocol is the foundation for achieving communication between agents and other entities in future network. |
| | ECH Considered Harmful |
| |
|
Encrypted Client Hello is designed to enhance personal privacy, in particular obstructing the ability of communications service providers (but not Over The Top service providers) to map packet flows to applications. While mostly ineffective in attaining this goal, it does severely hamper network-based detection of malicious flows, thus exposing end-users to various security risks that were previously avoidable. |
| | SSH File Transfer Protocol |
| |
|
The SSH File Transfer Protocol provides secure file transfer functionality over any secure and reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. |
| | Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and Encapsulating Security Payload (ESP) Protocols |
| |
|
This document specifies the use of AES-GCM-SIV in the Internet Key Exchange Protocol version 2 (IKEv2) and the Encapsulating Security Payload (ESP) protocols. This document also adds AES-GCM-SIV to the IANA IKEv2 registry for "Transform Type 1 - Encryption Algorithm Transform IDs." AES-GCM-SIV is a nonce misuse-resistant authenticated encryption with associated data (AEAD) algorithm based on AES-GCM. |
| | Enhancements to the YANG Language for Capturing Subtree Replacements |
| |
|
As YANG data models evolve over time, model nodes are often deprecated or made obsolete. Current practices for documenting replacement paths for these nodes rely on unstructured external documents, making it difficult to programmatically identify and migrate to replacement nodes. This document proposes a YANG extension mechanism that embeds replacement path information directly within YANG models, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. |
| | Securing QUIC with MLS |
| |
| | draft-tian-quic-quicmls-00.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Benjamin Dowling, Britta Hale, Konrad Kohbrok, Raphael Robert, Xisen Tian, Bhagya Wimalasiri |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how Messaging Layer Security (MLS) can be used in place of Transport Layer Security (TLS) to secure QUIC. |
| | Rich OAuth Error Responses |
| |
|
Define an error-handling protocol extension for the OAuth 2.0 token endpoint that allows the authorization server or resource server to specify an extra parameter on error responses that should be passed through to follow-up authorization requests. |
| | Deployment and Use of the Domain Name System(DNS) in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. |
| | Network Digital Twin based Architecture for AI driven Network Operations |
| |
| | draft-wmz-nmrg-agent-ndt-arch-00.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Qin WU, Cheng Zhou, Luis Contreras, Sai Han, Lionel Tailhardat, Yong-Geun Hong |
| | Working Group: |
Individual Submissions (none) |
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Integrating a Network Digital Twin into network management together with AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Network Digital Twin and AI which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together. It provides a cookbook of existing technologies to satisfy the architecture and realize intent-based networking to meet the needs of the network service. |
| | BGP Extensions to Enable BGP FlowSpec Based IFIT |
| |
|
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow- oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. So IFIT behavior can be applied to the specified flow automatically. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-13.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. |
| | Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
| |
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for SD-WAN Customer Premises Equipment (CPEs) to use GENEVE encapsulation (RFC8926) to transport IPsec-encrypted packets across a Cloud Backbone without requiring decryption at Cloud Gateways (GWs). In this approach, SD-WAN CPEs encapsulate IPsec-encrypted payloads within GENEVE headers and forward them to their nearest Cloud GWs. These Cloud GWs then steer the encrypted traffic through the Cloud Backbone while preserving its confidentiality, ensuring seamless transport to the destination Cloud GWs. The egress Cloud GWs subsequently deliver the original IPsec- encrypted payloads to the receiving CPEs. This mechanism enables the Cloud Backbone to interconnect multiple SD-WAN segments efficiently, eliminating the need for Cloud GWs to decrypt and re-encrypt payloads, thus enhancing the performance. |