| |
|
| |
| | Adding a Wrong Recipient URL for Handling Misdirected Emails |
| |
|
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. About This Document This note is to be removed before publishing as an RFC. Discussion of this document takes place on the MAILMAINT Working Group mailing list (mailto:mailmaint@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mailmaint/. Subscribe at https://www.ietf.org/mailman/listinfo/mailmaint/. Source for this draft and an issue tracker can be found at https://github.com/dweekly/ietf-wrong-recipient. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) or Link Layer Discovery Protocol (LLDP) in Software-Defined Networking (SDN). In a traditional Software-Defined Networking, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | IP Payload Compression excluding transport layer |
| |
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. |
| | Segment Routing Policy-Based Source Address Validation (SAV) Mechanism |
| |
|
This draft proposes a novel mechanism for Source Address Validation (SAV) message propagation based on Segment Routing policies (SR- policy). Traditional SAV mechanisms often rely on routing tables (RIB) and Policy-Based Routing (PBR), but these methods lack the flexibility and granularity needed for some network environments. By leveraging the flexibility and control capabilities of SR-policy, the proposed mechanism ensures that SAV messages are propagated along well-defined paths, ensuring efficient, secure, and accurate source address validation. |
| | IETF In Memoriam 2025 |
| |
|
The primary purpose of this memo is to remember substantial contributors to the Internet Engineering Task Force who have passed away in the year 2025. Some substantial contributors who died in prior years are also recognized. This memo is NOT a general memorial notice for the broader Internet community. Rather it is centered on persons who made notable contributions to IETF. This memo is NOT the product of any IETF or IRTF working group. It is published in the Independent RFC Stream consistent with guidelines in RFC4846. |
| |
|
| |
| | CBOR Simple Value for CSF |
| |
|
This document defines two CBOR "simple" values to be used as unique labels in a CBOR map holding an embedded signature. |
| | The Web of Agents (WoA) |
| |
|
This document defines the Web of Agents (WoA), a minimal JSON based description format and invocation convention that allows HTTP hosts to advertise AI agents and for clients to invoke those agents in a uniform way. A WoA document is typically served from a well known location on an HTTP origin and uses JSON Schema to describe agent inputs and outputs. WoA does not define a discovery protocol itself but is designed to be used as a host level primitive by higher level discovery systems. |
| | Agent Persistent State Profile |
| |
|
Autonomous agents increasingly maintain durable persistent state containing user preferences, embedding vectors, safety logs, intermediate reasoning steps, and audit traces. Today, agent frameworks treat storage as a generic file system, while storage administrators treat agents as stateless virtual machines. This "layer mismatch" leads to fragility, poor performance, and privacy risks. The Agent Persistent State (APS) Profile defines an experimental, vendor-neutral storage service class for durable agent state. APS emphasizes *compliance*: ensuring that memory associated with a specific user or agent identity can be retained, audited, and cryptographically erased. APS also addresses high-frequency small I/ O, vector index workloads, crash consistency, and Kubernetes/CSI [CSI] integration. APS introduces a Usage Class ("AgentPersistentState"), a versioned PersistentStateLineOfService schema, guidance for container orchestration systems, non-normative bindings for Swordfish [Swordfish] and Redfish [Redfish], and considerations for multi- tenancy. APS is intended as an Experimental RFC to gather implementation feedback prior to any standards-track work. |
| |
|
| |
| | MUD-Based RATS Resources Discovery |
| |
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | SOUTH: Stochastic Authorization for Agent and Service Requests |
| |
|
SOUTH defines an authorization protocol for evaluating requests issued by users, services, or autonomous agents. SOUTH allows a server to return a deterministic decision or an allow decision that is issued with a probability determined by local policy. This enables servers to incorporate uncertainty, contextual information, and load conditions into authorization decisions. SOUTH is transport independent and can be composed with existing authentication mechanisms such as OAuth, OpenID Connect, mutual TLS, or DPoP. This document describes the request and response objects, decision semantics, and an HTTP binding for interoperable deployment. |
| | Traceroute Framework |
| |
|
This draft introduces the development and latest situation of Traceroute, which is beneficial for network operators and users to understand the latest capabilities of traceroute, enabling them to utilize traceroute effectively. |
| |
|
| |
| | 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. |
| | Enhanced A2A Requirements for Agents Collobration in Enterprise |
| |
|
This document proposes enhanced requirements for the A2A protocol tailored to enterprise applications. |
| | Mail Pre-Flight Template Discovery Protocol (MPTDP) |
| |
|
This document specifies the Mail Pre-Flight Template Discovery Protocol (MPTDP). This mechanism allows a Mail User Agent (MUA) to proactively discover and retrieve a structured message template based on the recipient's public email address, prior to message composition. It utilizes a well-known URI structure and provides a security manifest to prevent address enumeration. |
| | SRv6 for Inter-Layer Network Programming |
| |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| |
|
| |
| | MISP core format |
| |
|
This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. |
| | OAuth Trust Binding Extension (OTBE) |
| |
|
This document defines the OAuth Trust Binding Extension (OTBE), a mechanism allowing Resource Owners to explicitly authorize which Authorization Servers may assert their identity towards Relying Parties, mitigating silent impersonation and namespace-based identity capture. |
| | AI Preferences Signaling: End User Impact |
| |
|
Standards can have a major impact on end users across technological, legal, ethical, and governance dimensions, largely centering around access to information, control over their digital contributions, and data privacy. The purpose of this Internet Draft is to document the potential impact of signaling AI preferences on end users other than publishers, and to suggest some principles for the ai-pref working group to consider when assessing proposed vocabulary and definitions IETF wishes to standardize for signaling. |
| |
|
| |
| | Compressed SID (CSID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. |
| | NTP Over PTP |
| |
|
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers that can timestamp only PTP messages and enables delay corrections in PTP transparent clocks. |
| |
|
| |
| | Multiple Loss Ratio Search |
| |
|
This document describes an alternative to "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) throughput by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and improve result repeatability and comparability. MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software-based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs purpose-built ASIC / NPU / FPGA hardware. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| |
|
| |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-21.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-19.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |