| |
|
| |
| | Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation |
| |
| | draft-ietf-acme-dns-persist-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Shiloh Heurich, Henry Birge-Lee, Michael Slaughter |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi- tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/ Browser Forum Baseline Requirements. |
| | RTP Payload Format for V-DMC |
| |
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-21.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. |
| | Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network. |
| | A YANG Data Model for Network Tester Management |
| |
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-18.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-19.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | DKIM2 Header Definitions |
| |
|
This document describes the email header fields defined for DKIM2, and how they work togther to provide the required properties. This is an early draft, a work in progress. |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. |
| | Advanced BGP Monitoring Protocol (BMP) Statistics Types |
| |
|
RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines new statistics type to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs). |
| | Intimate Partner Violence Digital Considerations |
| |
| | draft-irtf-hrpc-ipvc-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sofia Celi, Juliana Guerra, Mallory Knodel |
| | Working Group: |
Human Rights Protocol Considerations (hrpc) |
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These security compromises go beyond active and passive on-path attacks [RFC7624]. With a focus on protocols, the document describes tactics of the IPV attacker and potential counter-measures. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-09.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | LISP Virtual Private Networks (VPNs) |
| |
| | draft-ietf-lisp-vpn-13.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. |
| | External Trace ID for Configuration Tracing |
| |
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| | PCEP Extensions for Performance Measurements with Stateful PCE |
| |
| | draft-gandhi-pce-pm-09.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Rakesh Gandhi, Bin Wen, Colby Barth, Dhruv Dhody |
| | Working Group: |
Individual Submissions (none) |
|
In certain networks, network performance data such as packet loss, delay and delay variation as well as bandwidth utilization is a critical measure for Traffic Engineering (TE). This data provides operators the characteristics of their networks for performance evaluation that is required to ensure the Service Level Agreements (SLAs). The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs') requests. The Stateful PCE extensions allow Stateful control of Traffic Engineering Paths using PCEP for both RSVP and Segment Routing (SR). This document describes PCEP extensions for enabling and reporting end-to-end performance measurements for both PCE-Initiated and PCC- Initiated LSPs for both RSVP-TE and SR-TE (for MPLS and IPv6 Data planes) to an Active Stateful PCE. |
| | A Decent LISP Mapping System (LISP-Decent) |
| |
|
This draft describes how the LISP mapping system can be distributed for scale, decentralized for management and maintain trust among data-plane nodes. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | Agreements To Fix Forwarding |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. |
| | OpenPGP HTTP Keyserver Protocol |
| |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
| | draft-cxx-ippm-ioamaggr-04.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger |
| | Working Group: |
Individual Submissions (none) |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but its length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. |
| | Domain Related Group Support for EPP |
| |
|
This document defines an EPP extension allowing clients to learn about and manipulate related groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using SCONE protocol signalling, it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | Hybrid Post-quantum Key Exchange SM2-MLKEM for TLSv1.3 |
| |
|
This document specifies how to form a hybrid key exchange with CurveSM2 and MLKEM in Transport Layer Security (TLS) protocol version 1.3. Related IETF drafts include [hybrid] and [ecdhe-mlkem]. |
| | User Attributes in OpenPGP |
| |
|
This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. |
| | Split signing algorithms for COSE |
| |
|
This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. 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. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information, which contained in QUIC Header, QUIC Frame and Stream that traffic is being forwarded along with. |
| | Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol for IPv6 (ICMPv6) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMPv6 error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMPv6 error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMPv6. |
| | Requirements Analysis of System and Network for Large Language Model Inference Service |
| |
|
With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, such as vLLM, SGLang, Mooncake, etc. This paper investigates mainstream inference frameworks, summarizes their core design principle and research question, and analyzes the challenges and requirements they impose on network management. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. |
| | Fragmentation Revisited: For What It's Worth |
| |
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. |
| | ICMP Error Handling in SRv6 based VPN Networks |
| |
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). |
| | DomainKeys Identified Mail Signatures v2 (DKIM2) |
| |
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by applying a cryptographic signature to the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient further signatures will be added to provide a validatable "chain". This permits validators to identify when messages have been unexpectedly "replayed" and can ensure that delivery status notifications are only sent to entities that were involved in the transmission of a message. |
| | Call Placement Service (CPS) URI Certificate Extension for STI Certificates |
| |
|
This document specifies a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers authorized in a STIR Delegate Certificate. The extension enables originators and verifiers of STIR PASSporTs to discover, with a single certificate lookup, where Out- of-Band (OOB) PASSporTs can be retrieved. The mechanism removes bilateral CPS provisioning, allows ecosystem-scale discovery backed by STI Certificate Transparency (STI-CT), and is fully backward compatible with existing STIR certificates and OOB APIs. |
| | DACP: Data Access and Collaboration Protocol |
| |
| | draft-shenzhihong-dacp-01.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Zhihong Shen, Xiaojie Zhu, Zhenjing CHENG, Ziang Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Data Access and Collaboration Protocol (DACP), a communication protocol designed to support cross-node, cross-process data access in scientific and distributed computing environments. DACP provides standardized streaming-based data interactions over the Arrow Flight protocol and defines a unified Streaming DataFrame (SDF) model, which acts as a high-performance abstraction for accessing and processing both structured and unstructured data. |
| | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
|
This document defines a new otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a layer-2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension. |
| | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
|
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. |
| | The 'donau' URI scheme for validation of Donau donation statements. |
| |
| | draft-grothoff-donau-01.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Christian Grothoff, Emmanuel Benoist, Bohdan Potuzhnyi, Florian Dold |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the 'donau' Uniform Resource Identifier (URI) scheme for triggering interactions with a validator for Donau donation statements. This URI scheme allows applications to trigger interactions with a Donau validator. A Donau validator is typically run by a tax authority to validate tax records from citizens that made donations to a charity that supports the Donau protocol. The Donau validator will receive 'donau' URIs representing the sum of donations a taxpayer made to recognized charities over a year. Donors would submit 'donau' URLs (or QR codes with 'donau' URLs) to tax authorities to have their donations recognized by the tax authority as tax-deductible expenditures. The application logic to verify the validity of the donation is triggered by 'donau' URIs. The validator application would then typically confirm to the tax official the validity of the signature encoded in the URI and show the total amount donated as well as the taxpayer identification number and the year of the donation. Multiple URIs could be submitted per donor, and the application can correctly determine which submissions are cumulative and which ones are redundant. This specification only covers the syntax of the 'donau' URI scheme and excludes details on the protocol(s) that would allow taxpayers to donate to recognized charities to obtain these suitable signed donation statements. While a privacy-preserving protocol to obtain such statements exists within the context of the GNU Taler protocol suite, other protocols could be developed in the future and still yield compatible 'donau' URIs as the URI scheme is reasonably generic. The validation tool will be registered for all donau:// URIs. Since each taxation authority will typically use a different domain, it will not be feasible to encode all the domains of tax authorities servers inside the validation tool. Hence a new URI scheme is needed that will trigger the validation tool for any domain name. |
| | Generic Event Notification (GEN) for BGP Monitoring Protocol (BMP) |
| |
|
This document defines a new BMP message type: the Generic Event Notification (GEN). The BMP GEN message provides a flexible mechanism for reporting a wide variety of events related to BGP at different levels of hierarchy, such as routing instance, AFI/SAFI, or peer level. The BMP GEN message enables operators and automated systems to receive detailed context for operational events, such as policy triggers, administrative interventions, and state management notifications (e.g., RIB view unmonitor events). |
| | SONAR: Statistical Observation Network for Attestation and Reach |
| |
|
This document specifies SONAR (Statistical Observation Network for Attestation and Reach), a protocol combining three technical constructs to enable verifiable multicast distribution: (1) Physical layer efficiency through native IP multicast transmission achieving O(1) network bandwidth regardless of receiver population, (2) Cryptoeconomic receiver accountability via on-chain stake deposits, Verifiable Random Functions (VRF) for unpredictable sampling, and blockchain-recorded attestation reporting, and (3) Multicast source authentication through ALTA-based asymmetric loss-tolerant packet verification enabling real-time content integrity proofs. SONAR achieves constant 6% bandwidth overhead through separation of content authentication (broadcast to all receivers) from coverage verification (statistical sampling with German Tank Problem estimation). The protocol employs zero-knowledge proof aggregation via zkSNARKs for sample sizes exceeding 1,000 users, providing privacy protection (preventing on-chain correlation attacks), cost efficiency (80-90% reduction), and maintaining O(1) on-chain verification cost while scaling to populations exceeding 10^8 receivers. SONAR enables cryptographically verifiable multicast distribution without trusted intermediaries or per-receiver encryption overhead. |
| | Agent Identity Managenment |
| |
|
This document specifies agent identity management in the Internet of Agents (IOA) system. It defines the descriptive requirements for agent identities, the agent registration process, the structure and assignment of agent identifiers, and the basic and extended identity management functions performed by the agent gateway based on the agent's descriptive information. |
| | Enhanced A2A Requirements for Agents Collobration in Enterprise |
| |
|
This document proposes enhanced requirements for the A2A protocol tailored to enterprise applications. |
| | Agents Networking Framework for Enterprise and Broadband |
| |
|
This document introduces agents networking framework and defines the core components of agent networking in enterprise and broadband, as well as typical interactions among these key components. |
| | A Profile for Traffic Origin Authorizations (TOAs) |
| |
| | draft-qin-savnet-toa-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Lancheng Qin, Ben Maddison, Dan Li, Igor Lubashev |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. |
| | CARP - a CMAF compliant implementation of WARP |
| |
|
This document updates [WARP] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to WARP. |
| | The tag-42 profile of CBOR |
| |
|
This document defines a very narrow profile of CBOR intended for use with the special tag 42. Like the earlier internet-draft submitted under the name "CBOR Core," much of its design dates to the first CBOR RFC and predates much of the layered approach to determinism and profiling in later years. Also like "CBOR/c", CBOR-42 can be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR-42 objects link to one another by hash-based identifiers tagged "42", deterministic encoding is mandated to verify dereferenced links and encode new ones. |
| | Quantum Datagram Control Protocol (QDCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qdcp-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | External Relationship model for SIMAP |
| |
|
This document defines a SIMAP feature that enables modeling of external relationships between SIMAP entities and resources outside their core data models. It provides a templating approach to describe queries for external information, and an approach to link them to network elements. |
| | Rapid Startup of Congestion Control |
| |
|
This document defines Rapid Start, a congestion-control startup algorithm that grows the window by 3× per RTT until queue buildup is observed, so that a sender can reach the path BDP faster than with classic 2× slow start. When congestion is observed, Rapid Start immediately scales the window relative to the bytes that have passed through the bottleneck and then hands over to normal recovery and congestion avoidance. |
| | Using MUD in Constrained Environments |
| |
|
This document specifies additional ways for discovering and emitting Manufacturer Usage Descriptions (MUD), especially in constrained environments, utilizing the Constrained Application Protocol (CoAP), CoRE Resource Discovery, and CBOR Web Tokens. 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-romann-mud-constrained/. Source for this draft and an issue tracker can be found at https://github.com/namib-project/draft-coap-mud. |
| | A method for describing changes to emails |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. This method also captures hashes of important features of the message, allowing validation that the changes were described correctly, and allowing a signature which covers the Mail-Version header to, by extention, ensure that the important content of the message is unchanged. |
| | Scrubbing BGP ORIGIN Attribute |
| |
|
The BGP Origin attribute in its original meaning has been out of use for years. Yet, the BGP Origin attribute has high priority in the best route selection algorithm, right after the AS Path length, and it's being used inconsistently over the Internet to manipulate the route preference. This document updates RFC 4271 and RFC 7606 by making the BGP Origin attribute half-optional and explicitly allowing its scrubbing to zero (IGP). |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-ietf-nvo3-rfc7348bis-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This documents specifies Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This document obsoletes RFC7348 which documented the deployed VXLAN protocol for the benefit of the Internet community, and moves the VXLAN specification to the IETF document stream, allowing for the creation of extensions to VXLAN that require additions to the VXLAN header and their registration with IANA. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
| | draft-ietf-opsawg-yang-provenance-03.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integritu of datasets and/or data streams. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document specifies a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or deterministic and persistent path requirements are applicable. |
| | QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps |
| |
|
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-12.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ahmed Abdelsalam, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |
| | A well-known URI for publishing service parameters |
| |
| | draft-ietf-tls-wkech-11.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Stephen Farrell, Rich Salz, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record. |
| | Large Record Sizes for TLS and DTLS with Reduced Overhead |
| |
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^30 - 256 bytes, while reducing overhead. |
| | WIMSE Workload Credentials |
| |
| | draft-ietf-wimse-workload-creds-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Brian Campbell, Joseph Salowey, Arndt Schwenkschuster, Yaron Sheffer, Yaroslav Rosomakho |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. |
| | WIMSE Workload Proof Token |
| |
| | draft-ietf-wimse-wpt-00.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Brian Campbell, Arndt Schwenkschuster |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-level proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. |
| |
|
| |
| | Generic Address Assignment Option for 6LoWPAN Neighbor Discovery |
| |
| | draft-ietf-6lo-nd-gaao-08.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Luigi Iannone, David Lou, Adnan Rashid |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request. The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it can allow the user to see how the network modified the request as it traveled from the probing node to the probed node. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-14.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The document describes a RESTful application layer interface to perform operations on those devices, as well as a CBOR- based publish-subscribe interface for streaming data. |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
| | draft-ietf-bmwg-powerbench-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, Gen Chen |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. |
| | 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. |
| | BLS Signatures |
| |
| | draft-irtf-cfrg-bls-signature-06.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Dan Boneh, John Bradley, Sergey Gorbunov, Riad Wahby, Hoeteck Wee, Christopher Wood, Zhenfei Zhang |
| | Working Group: |
Crypto Forum (cfrg) |
|
BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. |
| | Pairing-Friendly Curves |
| |
|
Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. |
| | DKIM2 - signing the source and destination of every email |
| |
|
This memo provides a rationale for building a new email accountability mechanism, based on the lessons learned from implementing the ARC experiment from RFC 8617 and other experiences from email system operators. |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
This memo provides guidelines and documents Best Current Practice for operating authoritative DNS servers as well as recursive and stub DNS resolvers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance for how recursive DNS resolver should select upstream DNS servers, if synthesized and non-synthesized IPv6 addresses are available. This document obsoletes RFC3901. (if approved) |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-20.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Pradosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document defines a BGP Extended Community, the Link Bandwidth Extended Community, which carries link bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type. |
| | BGP Next Hop Dependent Characteristics Attribute |
| |
| | draft-ietf-idr-nhc-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Bruno Decraene, Kireeti Kompella, Serge Krier, MOHANTY Satya, John Scudder, Kevin Wang, Bin Wen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. |
| | BGP Entropy Label Characteristic |
| |
| | draft-ietf-idr-elc-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Bin Wen, Kevin Wang, John Scudder, MOHANTY Satya, Serge Krier, Kireeti Kompella, Bruno Decraene |
| | Working Group: |
Inter-Domain Routing (idr) |
|
The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) |
| |
| | draft-ietf-jose-hpke-encrypt-14.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key, and provides security against adaptive chosen ciphertext attacks (IND-CCA2-secure). HPKE also includes a variant that authenticates possession of a pre- shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document defines the use of HPKE with JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. |
| | IMAP OBJECTID Partial Implementation extention |
| |
|
This document extends the IMAP OBJECTID specification in RFC8474, which describes persistent identifiers for Mailboxes, Emails, and Threads in email. Some servers may be unable to provide persistent identifiers for some data types, but be able to provide them for others. This extension allows a server to specify that it can provide some objectids, without needing to implement all data types. |
| | Multicast YANG Data Model |
| |
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast streams. It provides a management view for network administrators to obtain information about multicast services. |
| | Multicast Redundant Ingress Router Failover |
| |
|
This document is intended to serve as a guide for multicast network operators of various replication technologies to evaluate the options and tradeoffs in deploying redundant ingress router failover. Section 5 of RFC9026 details the hot root standby solution for MVPN networks. Here we attempt to extend the discussion to cover additional multicast deployment solutions beyond MVPNs. This document compares cold, warm, and hot standby modes, listing their advantages, limitations and deployment considerations to help identify the appropriate solution for any network. |
| | NETCONF and RESTCONF Private Candidate Datastores |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | Remote Procedure Call over QUIC Version 1 |
| |
|
This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. |
| | Multi-Topology in PIM |
| |
| | draft-xz-pim-flex-algo-06.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Individual Submissions (none) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Supplement of BGP-LS Distribution for SR Policies and State |
| |
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags and a new sub-TLV are introduced in the SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks |
| |
|
This document defines a new type of segment for Segment Routing, 4map6 segment, along with its corresponding End.4map6 endpoint behavior. This behavior performs stateless IPv4/IPv6 translation or encapsulation at PE nodes based on stateless mapping rules, thereby enabling the delivery of IPv4 services over an IPv6-only network. At the same time, the BGP Prefix-SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. |
| | SCION Data Plane |
| |
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION Data Plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: 1. *Symmetric authentication protocol* - A protocol for the mutual recognition of entities based on a symmetric exchange of authentication messages through the mediation of Identity Providers (IdPs). It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - The IdPs network infrastructure that provides a secure environment for exchanging authentication messages. 3. *Custodian concept* - A special category of IdPs to protect physical identity and personal data. The generic IdP is called "*_trustee_*" and is only responsible for digital authentication, while the special IdP called "*_custodian_*" has the legal right to process the individual's real data and maintain the relationship with the digital identity. Custodian acts under the direct control of the authorities of the individual's country. |
| | IGP Flexible Algorithm with Time Constraint |
| |
|
IGP Flexible Algorithm allows IGPs to compute constraint-based paths over the network using different types of metrics or constraints. This document defines a new type of constraint called "Time Constraint", which can be used to control the time period during which a Flex-Algorithm takes effect for constraint-based path calculation. Such mechanism may be useful in network scenarios where either the traffic demand or the characteristics of the network varies as a function of time. The procedures of using Time Constraint in Flexible Algorithm is also described. |
| | Documenting and Managing DNSSEC Algorithm Lifecycles |
| |
|
Cryptographic algorithms for DNSSEC go through multiple phases during their lifetime. They are created, tested, adopted, used, and deprecated over a period of time. This RFC defines phases for the DNSSEC algorithm lifecycle, and it defines the criteria for moving from one phase to the next. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
This document proposes extension for ICMPv6 to detect data plane failures for EVPN over SRv6. |
| | Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation |
| |
|
This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol (ICMP) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMP error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of- Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per- challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMP. |
| | RPKI Terminology |
| |
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times be inconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. |
| | CBOR Encoding for HTTPS-based YANG Notifications Transport |
| |
|
This document extends [I-D.draft-ietf-netconf-https-notif] by introducing CBOR encoding for YANG notifications over HTTPS Transport in addition to the existing JSON and XML encoding schemes. |
| | Network File System version 4.2 COPY Operation Implementation Experience |
| |
|
This document describes the authors' experience implementing the NFSv4.2 COPY operation, as described in [RFC7862]. It then recommends and motivates updates to that document. This is not a normative document. |
| | RESTful Provisioning Protocol (RPP) |
| |
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. |
| | DNS-based Service Discovery for Computing-Aware Traffic Steering (CATS) |
| |
|
This document specifies how DNS-based Service Discovery (DNS-SD) can be used as a discovery and resolving method for mapping service identifiers to specific addresses within the CATS framework. It details extensions to DNS-SD to support CATS-specific service discovery requirements and describes how the discovery mechanism integrates with other components of the CATS architecture to enable compuating-aware traffic steering. |
| | AI Network for Training,Inference,and Agentic Interactions |
| |
|
Artificial Intelligence (AI) is rapidly transforming industries and everyday life, fueled by advances in model architectures, training paradigms, and data infrastructure for generation and consumption. Today, machine learning models are embedded in many of our daily activities, ranging from simple classification systems to advanced architectures such as large language models (LLMs) like ChatGPT, Claude, Grok, and DeepSeek. These models highlight the transformative potential of AI across diverse applications—from productivity tools to complex decision-making systems. However, the effectiveness and reliability of AI depend on two foundational processes: training and inference. Each process introduces unique challenges related to data management, computation, connectivity, privacy, trust, security, and governance. In this draft, we introduce the Data and Agent Aware-Inference and Training Network (DA-ITN)—a unified, intelligent, multi-plane network architecture designed to address the full spectrum of requirements needed to enable AI networks. DA-ITN provides a scalable and adaptive infrastructure that connects AI clients, data providers, model providers, agent providers, service facilitators, and computational resources to support end-to-end training, inference, and agentic interaction lifecycle operations. The architecture features dedicated control, data, and operations & management (OAM) planes to orchestrate training, inference, and agentic services while ensuring reliability, transparency, and accountability. By outlining the key requirements of such an AI ecosystem and demonstrating how DA-ITN fulfills them, this document presents an architecture for the future of AI-native networking—an "AI internet"—optimized for AI learning, efficient inference, scalable deployment, and seamless agent-to-agent collaboration. |
| | Multicast DNS-Based Service Discovery for Encrypted DNS Services |
| |
| | draft-liu-add-dnssd-edns-01.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Dongjie Liu, Zhiwei Yan, Guanggang Geng, Guoqiang Zeng |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks. It specifies new service types (_dot, _doh, _doq) and associated TXT record parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This extension addresses critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763. |
| | PPP IPCP Extensions for Encrypted DNS Server Negotiation |
| |
|
This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. These extensions allow PPP peers to exchange information about encrypted DNS servers supporting protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). The design maintains backward compatibility with RFC 1877 while addressing modern security requirements. |
| | Remote Procedure Call Identity Squashing via x.509 Certificate Fields |
| |
|
This document extends RPC-with-TLS, as described in [RFC9289], so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. |
| | Architecture for the Artificial Intelligence Internet Protocol (AIIP) |
| |
|
This document specifies the architectural model and core protocol behaviors for the Artificial Intelligence Internet Protocol (AIIP). AIIP provides a uniform way for agents, robots, tools, models, and services to be addressed and invoked either natively or through an HTTPS gateway. Beyond addressing, AIIP defines a _stateless compute_ profile in which endpoints do not retain caller data and each invocation returns a signed _execution receipt_. Receipts are REQUIRED to be attested with Trusted Execution Environment (TEE) evidence and MAY additionally include zero-knowledge proofs (ZKPs). Receipts MAY also be anchored to external settlement systems without exposing user data. |
| | SRv6 Policy Selector |
| |
|
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes a policy selection mechanism among the candidate SRv6 Policies based on network quality in IPv6 environments. |
| | Reservation of IPv6 Address Block 44::/16 for Amateur Radio Digital Communications (44Net) |
| |
|
This document proposes the reservation of the IPv6 address block 44::/16 for use by the global amateur radio community. The allocation would serve as the IPv6 successor to the legacy IPv4 network 44.0.0.0/8, historically known as AMPRNet or 44Net, which has provided a unified, non-commercial address space for amateur radio digital communications for more than four decades. The goal of this proposal is to maintain global cohesion and routing consistency for amateur radio networks as they transition to IPv6, while preserving the service's unique social and regulatory context. Amateur networks operate under national licensing frameworks and are limited to educational, experimental, and public-service purposes, distinguishing them from commercial Internet use. The proposed prefix would remain part of the global unicast routing table, enabling interoperability, research, and gateway connectivity between amateur systems and the wider Internet. This document outlines the historical rationale for an amateur radio IPv6 allocation, describes the technical and governance considerations for maintaining a contiguous and hierarchically managed address space, and specifies the IANA action required to reserve 44::/16 as a special-purpose global IPv6 prefix for amateur radio use. |
| | Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) |
| |
|
In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements. |
| | Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation |
| |
|
The Model Context Protocol (MCP) is an open standard that enables Large Language Model (LLM) applications to seamlessly integrate with external data sources and tools by exposing Resources, Prompts and Tools in a JSON-RPC 2.0 transport. This document describes a mapping of MCP roles, primitives and security model to the network management domain so that network devices act as MCP servers and network controllers act as MCP clients. This document also extends the model to Device-to-Device (D2D) collaboration, allowing network elements to perform distributed fault correlation when the controller is unreachable or when real-time cross-device data is required. The goal is to provide an intent-based, conversational and secure approach for automated network troubleshooting, configuration validation, and closed-loop remediation without inventing new protocols or device agents. |
| | MCP-based Network Measurement Framework: Using Model Context Protocol for Intelligent Network Measurement |
| |
|
This document proposes a framework for intelligent network measurement using the Model Context Protocol (MCP). By treating network devices as MCP servers, and treating network controllers, management systems, or network devices with LLM capability as MCP clients, this framework enables natural language-driven, AI-assisted network measurement operations. The framework leverages MCP's standardized communication protocol to provide real-time network performance monitoring, intelligent fault diagnosis, topology discovery, and automated measurement workflows. This document describes the architecture, use cases, and security considerations for implementing MCP-based network measurement systems. |
| | Network Notifications Problem Statement |
| |
| | draft-dong-fantel-problem-statement-01.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Jie Dong, Mike McBride, Francois Clad, Zhaohui Zhang, Yongqing Zhu, Xiaohu Xu, Rui Zhuang, Ran Pang, Hao Lu, Yadong Liu, Luis Contreras, DURMUS Mehmet |
| | Working Group: |
Individual Submissions (none) |
|
Modern networks require adaptive traffic manipulation including Traffic Engineering (TE), load balancing, flow control and protection etc. to support applications like AI training and real-time services. A good and timely understanding of network operational status, such as congestion and failures, can help to improve utilization, reduce latency, and enable faster response to critical events. This document describes the existing problems and why the IETF may need a new set of network notification related solutions to support any high-throughput, low-latency and lossless application. |
| | Scheduling Network Resources for Machine Learning Clusters |
| |
|
Large Language Models (LLMs) are pushing the boundaries of technology. The scale that they have reached currently vastly exceeds the capacity of any single compute unit (XPU); this requires a distributed approach where multiple XPUs are connected via a "backend" network, sometimes in a single data center, but increasingly in multiple data centers connected by a "data center interconnect" (DCI). We are approaching the point where the scale exceeds that of a single data center, thus requiring multiple such data centers connected via a "data center interconnect" network. Training and inferencing are expensive and critical operations, thus they are typically scheduled, i.e., the (compute) resources they need are carefully estimated, allocated and deployed so that these resources are efficiently used. However, while compute investment in these LLM processing clusters dwarfs that of networks, it is becoming increasingly clear that the latter can greatly impact the former. This has been the focus of recent conferences, including the fantel Birds of a Feather meeting in IETF 123, @Scale: Networking 2025 and Open Compute Project 2025. This memo proposes that the same care that is taken regarding allocation of compute resources to jobs be taken with networking resources: that they are estimated, allocated and deployed alongside compute resources; that they have contingency plans in case of network glitches; and that a holistic view be taken in order to optimize job completion times of training and inferencing jobs. |
| | Graph based Meta Schema for collaborative Operations |
| |
|
Graph based Meta Schema for collaborative Operation |
| | TESLA Update for GNSS SBAS Authentication |
| |
|
This document updates TESLA [RFC4082] to current cryptographic methods for use by the International Civil Aviation Organization (ICAO) in their Global Navigation Satellite System (GNSS) Satellite- based augmentation system (SBAS) authentication protocol. The TESLA updates are to align it with current best practices. |
| | Export of Source Address Validation (SAV) Information in IPFIX |
| |
| | draft-cao-opsawg-ipfix-sav-01.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Qian Cao, Mingqing(Michael) Huang, Benoit Claise, Tianran Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to verify SAV effectiveness, audit rule correctness, and analyze source address spoofing events. |
| | JMAP Object Metadata |
| |
|
This document defines a new extension to the JSON Meta Application Protocol (JMAP) that introduces a standardized mechanism for managing metadata associated with JMAP objects. The JMAP Object Metadata extension allows clients and servers to store, retrieve, and synchronize arbitrary metadata and annotations on any JMAP data type in a consistent manner. It defines a generic annotation model as well as specific mappings for accessing IMAP metadata and WebDAV “dead properties” where applicable. This extension facilitates interoperability between JMAP and existing metadata frameworks while allowing vendor-specific extensions in a structured and discoverable way. |
| | JMAP Enhanced Result References |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that enhances the result reference mechanism defined in [RFC8620]. The extension allows result references to be used in additional contexts beyond method call arguments, specifically within object properties during JMAP /set operations and within FilterCondition objects used in /query operations. Additionally, this specification extends result references to support JSON Path expressions ([RFC9535]) as an alternative to JSON Pointer ([RFC6901]), providing more expressive query capabilities for extracting values from previous method call results. These enhancements enable more efficient data reuse patterns across JMAP method calls, reducing the need for multiple round trips between client and server. |
| | JMAP Mail Sharing |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) for Mail to enable sharing of mailboxes between users. Building upon the JMAP Sharing framework defined in [RFC9670], this specification extends the Mailbox data type defined in [RFC8621] with properties necessary to configure and manage access permissions for shared mailboxes. The extension introduces a new capability that indicates server support for mailbox sharing and defines the additional properties required to share mailboxes with other principals, including the ability to control which users may access a mailbox and what permissions they possess. |
| | IMAP OBJECTID Account Identifier extension |
| |
|
This document extends the IMAP OBJECTID extension (RFC 8474) to support account identifiers, enabling IMAP servers to provide account-level context for mailboxes when multiple accounts are accessible through a single IMAP connection. This extension is particularly relevant for environments where IMAP mailboxes include shared mailboxes from multiple JMAP accounts, as defined in the JSON Meta Application Protocol (JMAP). By introducing the ACCOUNTID object identifier, this specification ensures that mailboxes can be uniquely identified across different accounts in both IMAP and JMAP contexts, thereby facilitating seamless interoperability between the two protocols in multi-account scenarios. |
| | Secure Asset Transfer Protocol (SATP) Terminology |
| |
|
This memo collates existing terminology related to digital assets, asset networks and distributed ledger technology (DLT) that are relevant to the secure asset transfer protocol (SATP) and the IETF more broadly. Existing terms are borrowed as much as possible, and new terms are introduced only when necessary and with emphasis on technology neutrality. |
| | NTPv5 Timestamp Extension Field |
| |
|
This document describes an alternative timestamp to the Monotonic Receive Timestamp Extension Field defined in NTP version 5 (NTPv5) when transferring frequency offset. The new extension field, named Monotonic RAW Receive Timestamp Extension Field uses a stable clock source that is not affected by NTP adjustment. It provides more accurate frequency-transfer offset between a remote server and local client, which further enhances the accuracy of time synchronization. |
| | DNS Resource Records for the Data Interoperability Protocol |
| |
|
This document specifies a set of new DNS Resource Record (RR) types to support the Data Interoperability Protocol (DIP). DIP models entities as "Data Objects" (DOs) indexed by "Data Object Identifiers" (DOIs), which are syntactically equivalent to DNS domain names. The RR types specified herein-DLR, DOPK, DOAUTH, DODIGEST, DOCG, and DOALGO-are designed to hold key attributes of a DO. This approach addresses the inherent limitations of repurposing existing RR types (such as TXT) with respect to structured data representation, efficiency in handling binary data, and query granularity. The result is a native, efficient, and extensible mechanism for discovering and managing DO metadata via the DNS. |
| | Advertisement of Algorithm in BGP |
| |
|
This document proposes extensions to BGP to support algorithm-based end-to-end path establishment. |
| | Model Context Protocol (MCP) Extensions for Network Equipment Management |
| |
| | draft-zw-opsawg-mcp-network-mgmt-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Guanming Zeng, Jianwei Mao, Bing Liu, Xiaotong Shang, Qiangzhou Gao, Zhenbin Li, Qin WU |
| | Working Group: |
Individual Submissions (none) |
|
The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework for interaction between AI applications and external context sources. This document specifies minimal extensions that allow network equipment (routers, switches, etc.) to act as MCP servers while controllers act as MCP clients. New capability tokens, tools, resources, prompts, and error codes are defined without breaking existing MCP implementations. |
| | Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-Based Networking |
| |
| | draft-zeng-opsawg-llm-netconf-gap-00.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Guanming Zeng, Jianwei Mao, Bing Liu, Nan Geng, Xiaotong Shang, Qiangzhou Gao, Zhenbin Li |
| | Working Group: |
Individual Submissions (none) |
|
Large Language Models (LLMs) are entering network operations through natural-language intent interfaces. Existing south-bound protocols (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for conversational, semantically-rich, multi-agent orchestration. This document provides a systematic gap analysis and identifies extension points for each protocol to meet intent-based networking requirements. |
| | When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios |
| |
|
NETCONF provides robust configuration transactions and YANG-based data models, but falls short in scenarios requiring AI-driven semantic translation, long-lived cross-domain orchestration, multi- agent consensus, rapid DevOps iteration, or delivery of large non- configuration artifacts. This document systematically analyzes the functional gaps and presents Model Context Protocol (MCP) and Agent- to-Agent (A2A) as complementary solutions. Implementation guidance and coexistence models are also provided. |
| | Network AI Agent Use Cases and Requirements in 6G |
| |
|
This draft introduces use cases related to network AI agents in 6G, with a focus on the interaction workflows of network AI agents in two distinct scenarios: connectivity services and third-party application services. These use cases primarily draw upon 6G-related scenarios outlined in the 3GPP technical report [TR22.870]. Furthermore, the document elaborates on the integration of network AI agents within the 6G framework and discusses corresponding network requirements. |
| | Agent Networking Scenarios of Digital Banking |
| |
|
This document describes several typical digital banking scenarios, and discusses the trend of banking digitalization evolving to agentic service inteconnection. Then, this document proposes an agent networking architecture based on the core component which is agent gateway. |
| | Zero trust standards in IETF: use cases and problem statement |
| |
|
The traditional "castle-and-moat" security paradigm is no longer effective for some emerging scenarios, such as cloud services, remote workforces and intelligent agents. Zero trust (ZT) has emerged as the new paradigm, holding on the "never trust, always verify" principle, treats every single access request as untrudted and requires veficication. While a high-level atchitectural guidance exists, notably from NIST in SP 800-207 where thtenants of zero trust are well interperated, the industry lacks the open, interoperable framework and protocol necessary for building multi-vendor zero trust practice enrironment. This document presents the problem statement for zero trust interoperability, outlines the key use cases, and argue for the need for standardization in the IETF. It discusses the possible scope for zero trust standardization work in the IETF, identifying which aspects are well suited for the IETF protocols and which are better addressed by other bodies. The aim of this document is to initiate a discussion in the IETF community on the necessity and prospective of promoting zero trust related work here. |
| | SOCKS: A Protocol for TCP Proxy Across Firewalls |
| |
|
This document is published as a historical record of the SOCKS 4 protocol. The original spec does not have an Abstract, so the Abstract below is added afterwards. This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. |
| | Requiring Support for Appealing to the IESG and IAB |
| |
|
RFC2026 describes the procedure for appealing decisions or process failures to the IESG and the IAB. This document updates RFC2026 and requires that an appellant must first gain support for their appeal before an appeal may be considered by the body it is submitted to. |
| | The IETF Chair May Delegate |
| |
|
This document proposes that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates several existing RFCs to enable that. It also proposes a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. |
| | Requirements for Agent Gateway |
| |
|
This document discusses the requirements for introducing Agent Gateways into Agent-to-Agent communications for better scalability, communication efficiency, and security etc. This document also discusses the gaps of current hardware/software gateways that could not fulfil the task, so that a new kind of entity, e.g. Agent Gateway, is needed. |
| | Encoding rules of YANG 'instance-identifier' in the Concise Binary Object Representation (CBOR) |
| |
|
Encoding rules of YANG-CBOR [RFC9254] are incomplete for 'instance- identifier' YANG data type. This document defines missing encoding rules for this data type. |
| | The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation |
| |
|
This document registers a Well-Known URI, /.well-known/awp.json, and a companion Link Relation Type, awp. The resource exposes a small, machine-readable description of common website workflows (states, actions, and resulting events) so automated agents can act predictably without scraping. The format is JSON and intentionally minimal. |
| | NAT64 WKP |
| |
|
This document removes the requirement in Section 3.1 of RFC6052 that the NAT64 Well-Known Prefix 64:FF9B::/96 MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. |
| | Use Cases and Requirements of Communication Protocol for Measurement Agents on Network Devices |
| |
|
This document focuses on the use cases and requirements of communication protocols for measurement agents on network devices. |
| | Use Cases and Requirements of Communication Protocol for Troubleshooting Agents on Network Devices |
| |
|
This document focuses on the use cases and requirements of communication protocols for troubleshooting agents on network devices. |
| | A Packet Marking Policy for Low Latency,Low Loss,and Scalable Throughput (L4S) |
| |
|
Low Latency, Low Loss, and Scalable Throughput (L4S)[RFC9330] is a technology designed to mitigate queueing delays while maintaining high throughput for IP traffic. In real-time communication (RTC) applications over 5G networks, rapidly fluctuating wireless link conditions impose strict requirements on congestion control algorithms, which must simultaneously ensure low latency and high bandwidth utilization. This document proposes a packet marking policy for L4S in 5G networks, where intermediate base station devices compute a link load factor and use it as a probabilistic signal to mark packets in L4S flows. |
| | AI Governance and Accountability Protocol (AIGA) |
| |
|
This document specifies the AI Governance and Accountability (AIGA) Protocol version 1.0, a practical, economically viable, and technically enforceable framework for governing autonomous AI agents. AIGA 1.0 is designed to address real-world deployment constraints, adversarial agent scenarios, and economic incentive alignment. The protocol is founded on a Tiered Risk-Based Governance model, applying proportional oversight to agents based on their capabilities. All agents are governed by an Immutable Kernel Architecture which provides a non-modifiable Trusted Computing Base (TCB) for enforcing policy. This is combined with Action-Based Authorization, where critical operations require real-time approval. To solve the single-point-of-failure problem, the protocol uses a Federated Authority Network of regional, cross-validating hubs and provides a Network-Level Quarantine Protocol for enforcement. The entire framework is designed around Economic Incentive Alignment, making compliance the most economically rational choice for operators. For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced, redundant mechanisms including Multi-Vendor TEE Attestation (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB) Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and Double Ratchet Cryptography. |
| | Secure Asset Exchange Protocol |
| |
|
This document describes the Secure Asset Exchange (SAE) Protocol. SAE is an extension of the Secure Asset Transfer (SAT) Protocol that enables the asset exchange interoperability mode. It specifies the required modifications necessary to the SAT message flows to facilitate asset exchange between asset networks. Gateways that support the SAT protocol can be extended to also support SAE, enabling support for both asset transfer and asset exchange in a single set of gateways. |
| | Export of Path Segment Identifier Information in IPFIX |
| |
|
This document introduces new IPFIX Information Elements to identify the Path Segment Identifier(PSID)s for SR-MPLS and SRv6 paths identification. |
| | Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-12.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-16.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| | Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token Specification to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. This draft updates RFC7643 defining additional attributes for "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema and updates RFC7644 with optional new Asynchronous SCIM Request capability. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-12.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "circuit-style" SR Policy (CS-SR Policy). |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces |
| |
| | draft-ietf-teas-yang-te-40.txt |
| | Date: |
02/11/2025 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. |
| | Workload Identifier |
| |
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |
| | Workload Authentication Using Mutual TLS |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). |
| |
|
| |
| | dCBOR: Deterministic CBOR |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The present document specifies dCBOR, a set of narrowing rules for CBOR that can be used to help achieve interoperable deterministic encoding for a variety of applications desiring a narrow and clearly defined set of choices. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Mobile nodes that operate in air/land/sea/space domains (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that supports mobile node coordination with a network-based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) and mobility service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI use IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. AERO is a widely-applicable service especially well-suited for air/land/sea/space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | IPv6 Addresses for Ad Hoc Networks |
| |
|
Ad Hoc networks present an IPv6 addressing challenge due to the undetermined neighborhood properties of their interfaces. IPv6 nodes must assign locally-unique and topology-independent IPv6 addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type (termed the "Multilink Local Address (MLA)") that nodes can autonomously assign to interfaces to support Ad Hoc network operations. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptographic algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform-agnostic profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. For enhanced strictness, as well as for enabling cryptographic methods like signing and hashing, to optionally be applied to "raw" (non-wrapped) CBOR data, deterministic encoding is mandated. Furthermore, the document outlines API features for manipulating CBOR data in a secure manner. This document mainly targets CBOR tool developers. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | Cross-device Communication Framework for AI Agents in Network Devices |
| |
|
With the development of large language models (LLM), AI Agent software continues to emerge. AI agents deployed on different network devices need to collaborate to accomplish some complex tasks, such as network measurement and network troubleshooting. This collaboration requires cross-device communication between AI agents. This document proposes a cross-device communication framework for AI agents in network devices, and analyzes the requirements for the communication protocol. |
| | Gap Analysis for the Cross-device Communication Protocol for AI Agents in Network Devices |
| |
|
With the development of large language models (LLM), AI Agent software continues to emerge. AI agents deployed on different network devices need to collaborate to accomplish some complex tasks, such as network measurement and network troubleshooting. This collaboration requires cross-device communication between AI agents. The cross-device communication framework is defined in [I-D.mzsg-rtgwg-agent-cross-device-comm-framework]. This document describes whether some classical protocols in networking area, and some popular ones in AI Agent area can be used for the cross-device interaction of the AI agents in network devices, and analyzes the gaps. |
| | APN Framework for Internet of Agent (IoA) |
| |
|
With the rapid development of large model technologies in the AI field, it has become possible to develop more intelligent assistant software, which is currently referred to as AI Agents in the industry. These agents may come from different manufacturers and be deployed on different cloud platforms and regions. They need to communicate and collaborate with each other through the Internet, which is called Internet of Agents (IoA). Different interactions of AI agents have varying task requirements, which also lead to different demands on the network. This requires network providing various fine granular services for the interactions of AI agents. This document proposes the application of the APN framework in the IoA scenario and analyzes its necessity. |
| | Security Requirements for AI Agents |
| |
|
This document discusses security requirements for AI agents, covering different stages of security interactions. These include provisioning, registration, cross-domain interconnection, and access control. |
| | Use cases of the AI Network Traffic Optimization Agent |
| |
|
This document introduces AI Network Traffic Optimization Agents as a dynamic alternative to traditional static network optimization methods. These AI entities analyze real-time network status (e.g., latency, node load) and adjust resources flexibly—deployed centrally or on devices—to enhance efficiency, ensure service quality, and cut operational costs. It defines network traffic optimization (maximizing resource use, meeting QoS) and AI agents (autonomous, learning entities that reduce manual work), then details three key application scenarios: tunnel adjustment (adaptive routing, predictive bandwidth, fault recovery), traffic steering (classification, application-aware policies, pre-emptive load balancing), and network slice adjustment (lifecycle automation, SLA compliance, slice-specific fault fixes). The document emphasizes the agents’ role in enabling SLA-compliant, autonomous optimization for complex networks. |
| | A Deterministic Algorithm for Resolving Shortlinks with Internal Redirects |
| |
|
This document specifies a deterministic algorithm for resolving shortlinks (compact string identifiers) into fully-qualified URLs. The algorithm supports both absolute URL destinations and origin- relative internal redirects with loop protection. It defines deterministic precedence rules for combining query parameters and fragments from multiple sources during resolution, enabling consistent behavior across clients, servers, and command-line tools. |
| | Use cases of the AI Network Security Agent |
| |
|
Core network devices like routers fulfill dual roles of data forwarding and security protection. However, escalating threats (e.g., zero-day vulnerabilities, DDoS attacks) expose limitations of traditional security—relying on static ACLs, signature-based detection, and manual configuration—causing delayed responses, high false positives, and protection gaps. This paper proposes AI Network Security Agents: intelligent software components leveraging machine learning, behavioral analysis, and real-time data fusion, with three core capabilities (adaptive learning, automation, distributed collaboration) to shift security from passive to intelligent. Four key scenarios are outlined: dynamic defense against unknown threats via baselines and tracing; ACL optimization via intent parsing; configuration security via baseline checks and simulation; and collaborative defense via intelligence aggregation and linked responses. AI Agents turn routers into active security orchestrators, enhancing threat protection and operational efficiency. |
| | A CBOR Tag for Lossless Transport of IEEE-754 NaN Bit Patterns |
| |
|
IEEE-754 NaN formations are not numbers and have no equivalence class. They are not comparable to anything, including reflexively, and therefore each attribute - sign bit, signaling/quiet bit, payload bits, and representation width (binary16, binary32, binary64) - can carry meaning for an implementation. CBOR permits encoding NaNs as floating-point values, but generic processing, preferred serialization, and deterministic profiles may canonicalize or otherwise alter NaN encodings, losing information. This document defines a CBOR tag, colloquially "nan-bstr", whose content is a byte string carrying the exact IEEE-754 NaN bit pattern so that all attributes are preserved across encode/decode, enabling use cases like NaN boxing, platform-specific error signaling, diagnostics, and forensics. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post-compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. |