| |
|
| |
| | Automatic Peering for SIP Trunks |
| |
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. |
| | Problems and Requirements of Addressing in Integrated Space-Terrestrial Network |
| |
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. |
| | LISP-Based Network for AI Infrastructure |
| |
|
The Locator/Identifier Separation Protocol (LISP) control plane provides the mechanisms to support Scale-Up, Scale-Out and Scale- Across backend networks within AI infrastructure. This document describes how LISP enables a unified control plane architecture that accommodates different scaling technologies, offering flexibility in deployment. By leveraging lisp mechanisms including EID-to-RLOC- mapping/pxTR registrations, publication-subscription and VPN instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf- lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the architecture delivers scalable high bandwidth for large training workloads, ultra-low-latency collective operations, and a simplified control framework that seamlessly spans heterogeneous accelerator fabrics. This approach allows AI/ML applications (whether focused on training or inference) to run workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. |
| | Architecture for the Artificial Intelligence Internet Protocol (AIIP) |
| |
|
This document defines the architectural model and byte-precise envelope framing for the Artificial Intelligence Internet Protocol (AIIP). AIIP enables stateless, verifiable invocation of autonomous systems using a resolve-invoke-receipt pattern over authenticated transports (mutual TLS, QUIC, or an optional HTTPS gateway). Native AIIP is the default for machine-to-machine operation; HTTPS gateways are optional for human-facing access. Each invocation produces a cryptographically verifiable execution receipt, optionally including attestation evidence. |
| | Export of Energy Consumption Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for exporting energy consumption information of physical entities in a network device. New Information Elements are defined to report instantaneous and average energy consumption information at device, line-card, and port granularity. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
| | draft-ietf-acme-rats-00.txt |
| | Date: |
12/12/2025 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide a Remote Attestation Evidence or Remote Attestation Result in any format supported by the Conceptual Message Wrapper. The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. This document updates the terms "Integrity fields" and "Integrity preference fields" defined in RFC 9530. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for SID verification for SR-MPLS |
| |
|
This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support SID verification in Segment Routing MPLS (SR-MPLS) networks. Specifically, it introduces a flag in the SR-ERO subobject to indicate that the Path Computation Client (PCC) is explicitly requested to verify SID(s) by the Path Computation Element (PCE), and defines capability exchange mechanisms. |
| | 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. |
| | Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
| |
| | draft-eckert-detnet-tcqf-11.txt |
| | Date: |
12/12/2025 |
| | Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. |
| | 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 providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of 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 systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and can also ensure that delivery status notifications are only sent to entities that were involved in the transmission of a message. |
| | Nearly IPv6 Only Dual Stack Hosts |
| |
|
Once all of a dual stack IPv4 and IPv6 host's applications support IPv6, IPv4 connectivity becomes unnecessary. However, ceasing to provide a dual stack host with an IPv4 address via a DHCPv4 server can cause the host to continue to make periodic and unsatisfied DHCPv4 requests, imposing unnecessary broadcast traffic on an attached link. In this situation, it would be useful to continue to provide a host with an IPv4 address via DHCPv4, yet prevent it from using the IPv4 address for any connectivity outside of the host itself. This memo describes a DHCPv4 method to achieve this. |
| | Additional Security Algorithms For Use With TCP-AO |
| |
|
RFC5926 specifies cryptographic algorithms for TCP-AO. It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC as KDFs. It also explains how to use HMAC-SHA-1-96 and AES-128-CMAC-96 as MAC algorithms. This document specifies several new KDFs and MAC algorithms for TCP- AO. The KDFs and MAC algorithms specified in this document are based upon more recent, stronger cryptography. |
| | Unified Transition Overlay (UTO): A Minimal Cross-Version Transport Mechanism for IPv4/IPv6 |
| |
|
This document specifies Unified Transition Overlay (UTO), a minimal encapsulation mechanism designed to enable bidirectional communication between IPv4-only and IPv6-only hosts without requiring NAT64, DNS64, heavy protocol translation, or global changes to Internet routing. UTO introduces a compact 12-byte header that carries a Remote Native Address (RNA) and allows a packet to traverse a network whose forwarding plane uses the opposite IP version. The underlying network remains purely IPv4 or purely IPv6, ensuring compatibility with existing hardware and reducing operational complexity. |
| | Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests |
| |
|
This specification describes extensions to the SUIT manifest format. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. |
| |
|
| |
| | RTP Payload Format for Haptics |
| |
|
This memo specifies an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS (MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for haptics/ hmpg, registered with IANA in RFC9695, did not include any required or optional parameters. This memo updates RFC9695 and the haptics/ hmpg registration to add optional parameters. It also provides SDP usage information for the haptics media type. |
| | JSContact Cryptographic Key Extensions |
| |
|
Extensions to the JSContact data model for contact card data are defined to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card. These features in combination provide a basis for establishing and maintaining peer- to-peer trust. |
| | Clarifications on CDS/CDNSKEY and CSYNC Consistency |
| |
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent- side Resource Record Sets (RRsets) of the delegation. This document specifies under which conditions the target states expressed via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side entities accepting such records from the child have to ensure that update requests retrieved from different authoritative nameservers satisfy these consistency requirements before taking any action based on them. This document updates RFC 7344 and RFC 7477. |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. This document when approved obosletes RFC8378. |
| | Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
| |
| | draft-eckert-detnet-glbf-07.txt |
| | Date: |
11/12/2025 |
| | Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| | Working Group: |
Individual Submissions (none) |
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. |
| | Latency analysis of mobile transmission |
| |
|
Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. |
| | STAMP Extensions for DetNet |
| |
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. |
| | IKEv2 Fragment Acknowledgment Extension |
| |
|
This document specifies an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) that enables acknowledgment of IKEv2 message fragments over UDP. The mechanism allows an IKE peer to confirm reception of individual fragments during the IKE_AUTH exchange and any subsequent exchanges where IKEv2 Fragmentation is used. Support for this feature is negotiated using a new Notify Message Status Type during IKE_SA_INIT, and fragment acknowledgments are exchanged using a separate Notification payload. This extension improves reliability when large IKE messages are exchanged, such as those containing post-quantum cryptography (PQC) payloads, and reduces retransmission overhead, thereby improving IKEv2 round-trip times in lossy network conditions. |
| | Modbus Serial Link Communication Security Protocol Specification |
| |
|
Currently, the industry has only standardized TLS-based security protocol for Modbus TCP communication. However, for EIA/TIA-485 multi-point systems, whether in 2-wire or 4-wire configurations, cables with a maximum baud rate of 9600 bit/s and AWG26 (or thicker) specifications can reach lengths over 1000m. For RS485 Modbus, sufficient cable diameter supports lengths over 1000m, and Category 5 cables can reach up to 600m. Despite its widespread use, Modbus serial link communication lacks standardized security mechanisms. As an application-layer industrial communication protocol, Modbus urgently requires targeted security standards for different deployment scenarios to enhance its security framework and ecosystem. For instance, in scenarios involving hardware side-channel attacks or long-distance relay and bridged networks, transmitting plaintext Modbus data over serial links risks data leakage or malicious modification by intermediaries, posing significant data and command security threats. To address this, it is critical to improve the communication security of Modbus in serial link mode by introducing encryption and authentication mechanisms. A proposed Modbus serial link security standard defines simple encryption and authentication methods to significantly enhance security while maintaining compatibility. This provides a straightforward upgrade path for existing Modbus-based devices, ensuring secure and practical applications in industrial control systems. |
| | Using IKE Fragmentation for Large Messages |
| |
|
This document describes describes issues with using Internet Key Exchange version 2 (IKEv2) fragmentation for transmitting large messages on unreliable transport. The document proposes several approaches for dealing with these issues: randomizing the order the fragments are sent, dispersing sending fragments over time and selective retransmission of fragments based on information from the peer about their receipt. |
| | The "HeaderWrittenBy" and "SendingSoftware" Mail Header Fields |
| |
|
This document proposes two new, optional mail header fields. * "HeaderWrittenBy" is designed to provide a simple attestation of the host that injected a message's primary author-level headers (such as "From") into the mail system. * "SendingSoftware" is designed to declare the Mail User Agent (MUA) that composed the message. These are intended to provide additional, simple-to-parse signals for mail filtering and analysis, to be used in conjunction with existing authentication mechanisms like DKIM. |
| | DNS driven traffic steering |
| |
|
The Internet provides best-effort service, and for users with quality assurance requirements, selecting an Internet acceleration service provider to gareentee network access quality is a common choice. This document proposes a possible mechanism for leveraging DNS to automatically steer application’s traffic onto an SRv6 network. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-23.txt |
| | Date: |
11/12/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. |
| | Versioning in the Registration Data Access Protocol (RDAP) |
| |
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. |
| | Protocol Numbers for SCHC |
| |
| | draft-ietf-schc-protocol-numbers-05.txt |
| | Date: |
11/12/2025 |
| | Authors: |
Robert Moskowitz, Pascal Thubert, Carles Gomez, Ana Minaburo, Marc Blanchet |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document requests an Internet Protocol Number, an Ethertype assignment, a CCSDS Encapsulation Number, and well known ports for SCHC. The SCHC architecture, the SCHC instance establishment, and the SCHC compression/decompression processes are simplified when SCHC is easily recognised. Well-known protocol and port numbers are needed. The Internet Protocol Number request is so that SCHC can be used for IP independent of other transports such as UDP and ESP. The Ethertype and the CCSDS Encapsulation Number are to support generic use of native SCHC over any IEEE 802 technology and CCSDS link layer technology, respectively, for IP and non-IP protocols. |
| | Distribute SRv6 Locator by DHCP |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment IDs are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through DHCPv6. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| |
|
| |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate. |
| | DNS Multiple QTYPEs |
| |
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. |
| | Advertising Unreachable Links in OSPF |
| |
|
In certain scenarios, it is necessary to advertise OSPF links that are not applicable to the default SPF (Shortest Path First) calculation for other purposes. In order to advertise these links and not use them in the base SPF calculation, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable. to be used MaxReachableLinkMetric (0xfffe) is defined to provide backward compatible reachability in specifications that previously specified advertisement of MaxLinkMetric (0xffff). This document updates RFC 5443, RFC 6987, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). |
| | OSPFv2 Anycast Property Advertisement |
| |
|
An IP prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | Cisco's CoAP Simple Management Protocol |
| |
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. |
| | Caller ID Verification In Heterogeneous Telecommunication Networks |
| |
| | draft-hao-civ-02.txt |
| | Date: |
10/12/2025 |
| | Authors: |
Feng Hao, Basil Thomas, Steve Smith, Muhammad Azad, Shen Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. |
| | The Ethical Crawler Agreement Protocol (ECAP) |
| |
|
This document specifies the Ethical Crawler Agreement Protocol (ECAP), an application-layer protocol for managing consent and ethical verification between web hosts and automated agents (crawlers, AI scrapers). Unlike the voluntary robots.txt standard, ECAP utilizes cryptographic signatures and a declarative policy handshake to ensure verifiable, consent-based access to web resources. |
| | The Micro Agent Communication Protocol (uACP) |
| |
| | draft-mallick-muacp-00.txt |
| | Date: |
10/12/2025 |
| | Authors: |
Arnab Mallick, Indraveni Chebolu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Micro Agent Communication Protocol (µACP), a resource-efficient messaging protocol for autonomous agents operating on constrained devices (Class 1 IoT devices per [RFC7228]). Existing agent communication protocols assume unbounded computational and energy resources; µACP provides formal guarantees on memory, energy, and bandwidth consumption while maintaining expressiveness sufficient for finite-state coordination patterns. The protocol defines four core message types, a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE security binding for operation in adversarial environments. |
| | The MyClerk Protocol: Tiered Security Communication for Distributed Family Systems |
| |
|
This document specifies the MyClerk Protocol, a tiered-security communication protocol designed for distributed family orchestration systems. The protocol provides six security tiers ranging from 1-byte minimal overhead for tunneled messages to 144-byte full security for critical operations. It supports multiple transport mechanisms including NATS, Matrix, WebSocket, and direct TCP, while maintaining end-to-end encryption using ChaCha20-Poly1305 and X25519 key exchange. The protocol is transport-agnostic, federation-capable, and optimized for environments ranging from resource-constrained IoT devices to full-featured desktop clients. |
| | The MyClerk Virtual File System: Distributed Storage for Family Networks |
| |
|
This document specifies the MyClerk Virtual File System (VFS), a distributed storage system designed for family networks. The VFS provides end-to-end encrypted, redundant storage across heterogeneous nodes using adaptive chunking and Reed-Solomon erasure coding [REED-SOLOMON]. Metadata synchronization uses Conflict-free Replicated Data Types (CRDTs) [CRDT] with a hybrid LWW-Register and OR-Set approach. The system supports tiered storage, automatic health monitoring with self-healing capabilities, and federation between separate family installations. It is designed to be accessible to non-technical users while providing enterprise-grade data durability. |
| | Token Status List (TSL) |
| |
|
This specification defines a status mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | Publishing End-Site Prefix Lengths |
| |
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen files which are comma-separated values (CSV) files used to specify end-site prefix lengths. This document also describes an optional mechanism that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen files. |
| | A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by the subject AS. |
| | PQ/T Hybrid Key Exchange with ML-KEM in SSH |
| |
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant the Module-Lattice- Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| |
|
| |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document specifies 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. |
| | 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. |
| | Mobile Traffic Steering |
| |
| | draft-ietf-dmm-mts-00.txt |
| | Date: |
09/12/2025 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | Guidance to Avoid Use of BGP Extended Communities at Internet Exchange Route Servers |
| |
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. This document updates RFC 7948. |
| | A YANG Data Model for In Situ Operations,Administration,and Maintenance (IOAM) Integrity Protected Options |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method to collect operational and telemetry information. The collected data may then be exported to systems that will use it to, e.g., monitor, measure, or (re)configure the network. Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields (RFC YYYY) defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the management of these Integrity Protected Options. |
| | Fast HIP Host Mobility |
| |
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. |
| | SRv6-based BGP Service Capability |
| |
|
RFC9252 specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis. This document provides analysis on the problems that may be encountered if the SRv6-based service routes are received by the MPLS-only PEs. Some currently used SRv6-based service routes advertisement controlling methods by configuration or network planning are also described. And this document proposes an automatic advertisement controlling method for SRv6-based service routes by defining a new Capability Code for SRv6-based BGP service capability. |
| | A Profile for Signed Group of Multiple-Origin Autonomous Systems for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document defines a "Signed MOAS Group", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to authenticate the collective announcement of IP prefixes by Multiple Origin Autonomous System (MOAS). The Signed MOAS Group mainly includes two parts: an IP prefix and a list of Autonomous Systems (ASes) authorized to announce the prefix. At least one of these ASes SHOULD be authorized to announce the prefix by the prefix owner through a Route Origin Authorization (ROA). The validation of a Signed MOAS Group confirms that the authorized ASes and other listed ASes have collectively agreed to announce the prefix, ensuring that the announcement is legitimate, accurate, and mutually authorized. |
| | Domain Name System (DNS) IANA Considerations |
| |
|
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record (RR) types, CLASSes, operation codes, error codes (RCODEs), DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6895 and updates RFCs 1183, 2930, 3597, and 8945. |
| | HTTP Profile for Synchronized Resource State (Agentic State Transfer) |
| |
|
HTTP resources are frequently exposed in multiple representations (e.g., text/html for rendering and application/json for processing) via Content Negotiation. However, standard HTTP concurrency controls (such as ETags) are typically scoped to the byte sequence of a specific representation. This creates a synchronization gap where a client modifying one representation cannot guarantee consistency with the underlying state of another representation, leading to race conditions and "lost updates" in multi-client environments. This document specifies _Agentic State Transfer_ (AST), an HTTP profile for managing _Canonical Resource State_ (CRS) across multiple synchronized representations of the same resource. It defines the use of _Semantic Validators_ (Content Identity) to track the logical state of a resource independent of its serialization. It further mandates the use of Optimistic Concurrency Control via If-Match headers for state-changing operations, ensuring that mutations applied by automated agents are atomic and consistent across all views. |
| | Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| | Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing |
| |
|
The RIFT (Routing in Fat Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e., Well-Known, OUI, and Experimental) and a method to structure corresponding values. It also defines a Well-Known Key Sub-Type used for testing tie-breaking behavior. |
| | A Comprehensive Errata for 'retransmission-allowed' XML Element |
| |
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. |
| | Secure Reporting of SUIT Update Status |
| |
| | draft-ietf-suit-report-18.txt |
| | Date: |
09/12/2025 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | A Voucher Artifact for Bootstrapping Protocols |
| |
| | draft-ietf-anima-rfc8366bis-20.txt |
| | Date: |
08/12/2025 |
| | Authors: |
Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines a strategy to securely assign a Pledge to an Owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of BRSKI/ RFC8995. |
| | YANG-CBOR: Allocating SID ranges for PEN holders |
| |
|
YANG-CBOR (RFC 9254) defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 defines ways to allocate these SIDs on the basis of IANA registries. The present specification employs these SID allocation mechanisms to allocate ranges with 100 000 63-bit SIDs each for each of the first 1 000 000 holders of IANA-registered Private Enterprise Numbers (PENs), as well as ranges with 10 000 32-bit SIDs each for each of the first 100 000 holders. // The present revision –04 is intended to address the feedback from // the AD review and the IETF last call. Note that due to a // regression in the bib.ietf.org service (https://github.com/ietf- // tools/bibxml-service/issues/489 (https://github.com/ietf-tools/ // bibxml-service/issues/489)), the reference // [IANA.enterprise-numbers] may come out as "*** BROKEN REFERENCE // ***" in some CI systems; this will certainly be fixed in the // course of further processing. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-05.txt |
| | Date: |
08/12/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. 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-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | SW103K PROTOCOL |
| |
|
The SW103k protocol addresses challenges in networks with limited bandwidth, latency constraints, and data integrity concerns. It provides compression and decompression to optimize bandwidth utilization in environments such as IoT, satellite, and mobile communications. The protocol operates at the data link layer with a custom frame format including SW103K and HAVI headers. Key features include: - Batch processing of 103 packets with compression - Merkle tree- based integrity verification (merklesw103k root hash) - QoS mechanisms with 8-bit priority field - Security features including AES-256-GCM encryption - Physical layer synchronization with +-1us accuracy Implementations include Linux kernel modules, FPGA encoders, and userspace daemons. The protocol supports interoperability with industrial standards like PROFINET and EtherCAT through custom mappings. |
| | Adaptive Routing Notification |
| |
|
Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and/or improve transport reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, is growing popular in commodity data centers to dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, the sensing node can not only apply AR locally but also send the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the reported path. This document specifies Adaptive Routing Notification (ARN), a general mechanism to proactively disseminate congestion detection and congestion elimination information for remote nodes to perform re-routing policies. Particularly for AI workloads like DeepSeek's MoE models that exhibit dynamic all-to-all communication patterns with bursty traffic characteristics, such mechanisms become crucial to enable immediate network response to transient congestion conflicts. |
| | PQ/T Hybrid KEM: HPKE with JOSE/COSE |
| |
|
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. |
| | Evidence Package Format Specification: Storing Evidence from Software Testing |
| |
|
Taking evidence is a key part of any robust software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. This work is not a standard and does not enjoy community consensus. |
| | An AuthZEN profile for trust registries |
| |
|
Trust registries come in many forms; ETSI trust status lists, OpenID Federation, ledgers. This document describes a simple protocol in the form of a profile of AuthZen that provides a local interface to one or more trust registries. The protocol is mant to be used as a local abstraction layer for any application that needs to evaluate trust. |
| | Managing multiple paths for a QUIC connection |
| |
| | draft-ietf-quic-multipath-18.txt |
| | Date: |
08/12/2025 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It proposes a standard way to create, delete, and manage paths using identifiers. It does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. |
| | EAT Measured Component |
| |
|
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated CoAP Content-Formats, enable the immediate use of the semantics within the EAT framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example using ASN.1. |
| | Encrypted Payloads in SUIT Manifests |
| |
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. |
| |
|
| |
| | Flooding Reduction Algorithms Framework |
| |
|
This document introduces a framework making it possible to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. |
| | MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) |
| |
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. |
| | Segment Routing Policy Extension for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. |
| | Privacy Preference Declaration for Home Networks |
| |
|
This document proposes a framework that empowers users to define and enforce privacy policies within their home networks through a Privacy Preference Declaration (PPD) protocol and architecture. As connected devices proliferate, this approach enhances user control by enabling user-defined privacy settings for different data types, automatic policy discovery by new devices, and accountability measures such as notifications, network restrictions, or perhaps reporting non- compliance with users' defined preferences to designated authorities. The framework aims to cultivate a privacy-conscious home network environment through clear, enforceable privacy governance. |
| | Privacy Preference Declaration Taxonomy |
| |
|
This document defines a standardized taxonomy for describing data handling practices of Internet-connected devices within home networks. It complements the Privacy Preference Declaration (PPD) Protocol and architecture by providing the necessary vocabulary and semantic structure to represent and reason about data types, purposes, actions, sources, and destinations. This taxonomy supports both machine reasoning and human interpretation and can be implemented using ontological frameworks such as OWL-DL. |
| | Transition to Full BGPsec Deployment: Transitive-BGPsec is Incompatible with BGPsec |
| |
|
This document elaborates on the reasons why it is unfeasible to reconstruct the native-BGPsec as a transitive approach, such that a BGP update with a correctly signed BGPsec_PATH attribute can traverse legacy areas and afterwards it can still be properly processed by subsequent native-BGPsec speakers. |
| | A Profile for Route Path Authorizations (RPAs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). |
| | Measurement and Analysis of IPv6 Interface Identifier Patterns in the Real World |
| |
|
Interface Identifiers (IIDs) are critical components of IPv6 addresses, significantly impacting user privacy and the feasibility of network reconnaissance. RFC 7707 previously provided a comprehensive analysis of IID patterns based on data from the early stages of IPv6 deployment. However, with the widespread adoption of privacy-enhancing standards such as RFC 7217, historical data no longer accurately reflects the current IPv6 ecosystem. This document provides updated measurements of IID patterns by utilizing an improved pattern recognition method and incorporating novel data sources, such as public mailing lists. The measurement data reveals that while "Low-byte" patterns have decreased significantly in server addresses, a substantial number of seemingly random addresses actually belong to non-random, specific patterns, implying that heuristic scanning remains a viable vector. Furthermore, while client devices have widely adopted randomized addresses-effectively enhancing privacy-Client Premise Equipment (CPE) routers continue to exhibit a high usage rate of IEEE EUI-64 addresses, constituting an often-overlooked privacy risk. This document aims to update the statistics and analysis regarding IID pattern distribution found in RFC 7707, providing essential insights for modern network defense strategies and standard compliance. |
| | A whitelist-based data fencing mechanism in data circulation |
| |
|
This document defines the data transaction permission fields within the Data Fencing architecture and the whitelist information maintained by the gateway devices. By comparing the data transaction permission fields against the whitelist, data packets are either permitted or blocked, establishing precise data flow boundaries and egress control. Finally, the document presents several use cases of the data fencing. |
| | A Token-efficient Data Layer for Agentic Communication |
| |
|
Agentic communication fundamentally differs from traditional machine communication in that its outputs are recursively consumed and interpreted by Large Language Models (LLMs). This unique characteristic makes efficient use of the model's limited context a critical requirement. However, current agent communication protocols - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) - often suffer from token or context bloat, caused by redundant schema definitions, verbose message structures, and inefficient capability exchanges. As a result, a substantial number of tokens are unnecessarily consumed within the model’s context window. To address these issues, this draft defines the Agentic Data Optimization Layer (ADOL), a general and foundational data-layer for agent communication. ADOL introduces a set of backward-compatible optimizations, including schema deduplication through JSON references, adaptive inclusion of optional fields, controllable response verbosity, and retrieval-based selection mechanisms. Collectively, these mechanisms reduce token consumption, enhance context efficiency, and provide a scalable foundation for future agent communication frameworks. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| |
|
| |
| | iCalendar Format Extensions for JSCalendar |
| |
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). |
| | CBOR Serialization and Determinism |
| |
|
This document defines two CBOR serializations: "ordinary serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the full, variable set of serialization options defined in [STD94]. Together, these three form a complete set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-07.txt |
| | Date: |
05/12/2025 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Template-Driven HTTP CONNECT Proxying for TCP |
| |
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| | BGP Dissemination of Flow Specification Rules for Tunneled Traffic |
| |
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. |
| | IETF Community Moderation |
| |
|
The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of guidelines and facilitate their consistent implementation with chairs and administrators. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document proposes four new optional file attributes for NFSv4.2 to support POSIX ACLs conforming to the withdrawn POSIX 1003.1e draft 17. Although never ratified, POSIX ACLs are implemented in widely deployed operating systems. Existing attempts to map between NFSv4 and POSIX ACL models have been unsuccessful due to semantic incompatibilities. These new attributes allow servers to expose POSIX ACLs directly, avoiding lossy mapping. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | Issue in Route Origin Validation from Route Partial Visibility |
| |
|
In the Resource Public Key Infrastructure (RPKI), validating prefix- origin pairs using Route Origin Authorizations (ROAs) globally and performing Route Origin Validation (ROV) locally at each Autonomous System (AS) with validated ROA payloads (VRPs) can lead to inconsistent results due to partial route visibility. This document highlights how partial route visibility can turn originally non-loose ROAs into loose VRPs, outlines the causes of partial route visibility, and discusses potential solutions to mitigate the issue. |
| | TESLA Update for GNSS SBAS Authentication |
| |
|
This document updates TESLA [RFC4082] to current cryptographic methods leveraging the work done 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 to this and other current best practices. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirements for the development of the RESTful Provisioning Protocol (RPP). |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-13.txt |
| | Date: |
05/12/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). |
| |
|
| |
| | Usage Limits on AEAD Algorithms |
| |
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a 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. This document obsoletes the corresponding parts of RFC 7489 and updates RFC 6591. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-24.txt |
| | Date: |
04/12/2025 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-22.txt |
| | Date: |
04/12/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 bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type. |
| | Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) |
| |
| | draft-ietf-mpls-stamp-00.txt |
| | Date: |
04/12/2025 |
| | Authors: |
Greg Mirsky, Li Zhang, Loa Andersson |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. |
| | A YANG Data Model for RESTCONF Clients and Servers |
| |
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. These modules support both standard and RESTCONF Call Home connections. |
| | A YANG Data Model for NETCONF Clients and Servers |
| |
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. These modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis respecification effort for NFSv4.1. It describes the structure and function of NFsv4 Access Control Lists within all existing minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. [Consensus Needed (Item #117a)]: Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was originally intended, this document clarifies the status of draft-POSIX ACLs, with the expectation that support for these might be provided via a later extension. In addition, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. [Consensus Needed (Item #117a)]: In this document, the relationship among the multiple ACL models for which support was intended has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now- withdrawn draft-POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft-POSIX ACL model are considered as OPTIONAL extensions to that core, with the latter not yet present in NFsv4.1. [RFC Editor: please remove this parapgraph and the following paragraph prior to publishing this document as an RFC]. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts provide a framework for addressing these issues and obtaining working group consensus regarding changes that will be necesasary before publication of RFCTBD10. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | 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. |
| | JSON Structure: Core |
| |
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. |
| | JSON Structure: Import |
| |
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. |
| | JSON Structure: Alternate Names and Descriptions |
| |
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. |
| | JSON Structure: Symbols,Scientific Units,and Currencies |
| |
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. JSON Structure Scientific Units provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. |
| | JSON Structure: Validation Extensions |
| |
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. |
| | JSON Structure: Conditional Composition |
| |
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. |
| | A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel Support |
| |
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. |
| | Concluding the ARC Experiment |
| |
|
This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol,” (RFC8617) and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail (DKIM). To avoid any future confusion, it is therefore requested that ARC (RFC8617) be marked “Obsolete” by the publication of this Internet-Draft. |
| | ChainSync: A Synchronization Protocol for Strict Sequential Execution in Linear Distributed Pipelines |
| |
|
ChainSync is a lightweight application-layer protocol that runs over reliable TCP connections to synchronize a fixed linear chain of distributed processes such that they execute their local tasks in strict sequential order and only after every process in the chain has confirmed it is ready. The protocol has four phases: 1) a forward "readiness" wave, 2) a backward "start" wave, 3) a forward "execution" wave, and 4) a backward exit wave. The design guarantees strict ordering even when nodes become ready at very different times and requires only point-to-point TCP connections along the chain, thus no central coordinator is needed. |
| | PCEP Extensions for Computing-Aware Traffic Steering (CATS) Service |
| |
|
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services. |
| | Automated Discovery Of Audit Reports (audits.json) |
| |
|
This document describes a mechanism that an organization can use to enable automatic discovery of documents associated with regulatory compliance. It is motivated by regulations that require, for example, publicly accessible audits of automated decision-making processes in hiring. |
| | Phi-Ns Cryptosystem |
| |
|
This document describes Phi-Ns, a new asymmetric cryptographic primitive based on the structured decomposition of the quadratic gap between two primes. Phi-Ns defines a public key q and a private key p such that the difference q^2 - p^2 is expressed as a composite value T. The value T is then factored into small controlled components noted a, b, and R, and the final secret structure abR is encoded through a randomized serialization process. The security of Phi-Ns does not rely on integer factorization, the discrete logarithm problem, or elliptic curves. Instead, it depends on the difficulty of recovering p from q when the attacker has no oracle, no structural anchor, and no method to determine whether a candidate p is correct. Because T can be recursively decomposed and reassembled into multiple unpredictable forms, the resulting search space grows combinatorially. Phi-Ns further supports recursive expansion of the internal abR structure, allowing the construction of high-entropy secret states even when p and q have relatively small bit lengths. This enables compact public keys, efficient computation, and strong post-quantum resistance based on a non-factorization hardness assumption. This document specifies the algorithmic model of Phi-Ns, its parameter choices, and the serialization rules used to encode the abR structure. It also outlines two public-key variants, PK-p and PK-q, which expose either p or q as the public value depending on deployment constraints. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | PEM file format for ECH |
| |
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. |
| | A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) |
| |
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a DER-encoded data interchange format which can be used to represent various aspects of the state of a validated cache at a particular point in time. The CCR profile is a compact and versatile format well-suited for a diverse set of applications such as audit trail keeping, validated payload dissemination, and analytics pipelines. |
| | The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| | RTP payload format for APV |
| |
| | draft-ietf-avtcore-rtp-apv-00.txt |
| | Date: |
03/12/2025 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APV) codec. |
| | 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). |
| | MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
| |
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute, used in conjunction with a specific AFI/SAFI combination for advertising IPv4-over-IPv6 mapping rules. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-11.txt |
| | Date: |
03/12/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. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. |
| | Consolidated Parameters Part for Multipart/Form-Data |
| |
|
This document describes a deployment pattern for reducing overhead in multipart/form-data requests that include both file uploads and numerous text parameters. The approach consolidates multiple text fields into one or more application/x-www-form-urlencoded parts inside the multipart body. This technique requires no changes to existing HTTP, MIME, or form specifications and is fully compatible with RFC 7578. It uses only existing, standardized Content-Type values in their already-defined manner, making it immediately deployable with current infrastructure. The pattern guarantees backward compatibility: servers that don't recognize it still receive all parameters as standard form data. RFC 7578 defines multipart/form-data but does not specify optimization strategies; this document fills that gap. This document records the pattern, processing rules, and deployment considerations, and reports implementation experience from production systems processing millions of uploads daily. |
| | High-Assurance Execution Environment (HAE) for Secure Approval |
| |
|
This document specifies the High-Assurance Execution Environment (HAE), a trusted, ephemeral approval environment designed to protect the authorization of high-risk digital and physical actions. |
| | PRE-RCT: Pre-Execution Authorization Receipt Format |
| |
|
This document defines PRE-RCT, the Pre-Execution Authorization Receipt, a cryptographically signed and attestation-aware receipt format used to record high-risk authorization events. PRE-RCT is intended for use with pre-execution authorization protocols such as GNA. |
| | HTTP Bearer Auth Method Extensions |
| |
|
This document specifies an improved HTTP 401 and 407 flow for Bearer authentication where user-agents (or client applications) can automatically fetch requested tokens from a Security Token Service (STS). A fallback to an OpenID Connect (OIDC) redirect flow is included. This improved 401/407 Bearer flow, when used, elides the need for Proof Key for Code Exchange (PKCE) and does not impose on application Universal Resource Identifier (URI) query parameter design. As well this extension allows for user-agent caching of tokens. |
| | Metadata Constrained Distribution |
| |
|
This document specifies a receiver-driven _Metadata Subscription_ (MDS) mechanism for BGP. A BGP speaker uses the new MDS NLRI to subscribe to specific service metadata attributes. |
| | OAuth 2.0 for Browser-Based Applications |
| |
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. |
| | A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
| |
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. |
| |
|
| |
| | An Application Layer Interface for Non-Internet-Connected Physical Components (NIPC) |
| |
| | draft-ietf-asdf-nipc-15.txt |
| | Date: |
02/12/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. |
| | Protocol Mapping for SDF |
| |
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using specific IP and non-IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. |
| | COSE (CBOR Object Signing and Encryption) Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. |
| | An Architecture for DNS-Bound Client and Sender Identities |
| |
| | draft-ietf-dance-architecture-10.txt |
| | Date: |
02/12/2025 |
| | Authors: |
Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson |
| | Working Group: |
DANE Authentication for Network Clients Everywhere (dance) |
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. |
| | Unobtrusive End-to-End Email Signatures |
| |
|
This document deals with end-to-end cryptographically signed email. It introduces a novel structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email. |
| | Validating anydata in YANG Library context |
| |
|
This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. |
| | Transient Hiding of Hop-by-Hop Options |
| |
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. |
| | Fast Congestion Notification Packet (CNP) in RoCEv2 Networks |
| |
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. |
| | Domain Transfer Authorization Using Cryptographic Signatures |
| |
|
This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a asymmetric cryptographic signature-based validation system. Using asymmetric cryptographic signatures enables many benefits over a shared secret, such as non-repudiation, improved auditability through clear identification of the authorizing entity, elimination of the need for registries to store and secure shared secrets, replay protection through timestamp validation, and reduced risk of interception since only the private key needs to remain secret. This document establishes the following AuthCodeSEC extension of EPP with the following protocol elements: |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines pure post-quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes for use in the SSH Transport Layer Protocol. |
| | Export of Encapsulation Layer Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for encapsulation layer indication to help with the scenario when monitoring flow with multi- layer network encapsulations. |
| | Revision to Locally Served DNS Zones Registry |
| |
|
RFC 6063, "Locally Served DNS Zones", defines two IANA registries called "IPv4 Locally-Served DNS Zone Registry" and "IPv6 Locally- Served DNS Zone Registry". This document changes the registration procedure for that registry from "IETF Review" to "Expert Review". This document updates RFC 6063. |
| | Extended Key Usage and Mutual TLS in EPP |
| |
|
This document describes the state of the Mutual Transport Layer Security (mTLS) client authentication mechanism in the Extensible Provisioning Protocol (EPP) with respect to a recent change in the client certificates published by some Certificate Authorities (CAs). The issue is described and options are presented to address the operational impact of the change. |
| | GuardNet Authorization Protocol (GNA): Pre-Execution Authorization for High-Risk Digital Actions |
| |
|
This document specifies the GuardNet Authorization Protocol (GNA), a pre-execution authorization framework for high-risk digital and physical actions. GNA defines an enforcement model in which sensitive operations (for example, payments, administrative changes, OT/ICS commands, and AI-initiated actions) are intercepted before execution, evaluated against policy and context, routed to one or more authenticated approvers, and executed only after a valid authorization token is issued. GNA provides non-repudiable authorization receipts and is designed to integrate with existing identity providers and logging systems without requiring architectural changes. The protocol provides stronger authorization guarantees using digital signatures and contextual decisioning and is intended as a complement to, not a replacement for, existing authentication and monitoring systems. |
| | GuardMail Protocol (GMP): Authenticated Messaging with Non-Repudiable Cryptographic Receipts |
| |
|
This document specifies the GuardMail Protocol (GMP), a framework for authenticated outbound messaging that provides cryptographic proof of origin, integrity, and policy compliance for email and file-based communications. GMP introduces GuardMail Receipts (GMRs), signed metadata structures bound to sender identity and message content that allow recipients to verify authenticity independent of transport mechanisms such as SPF, DKIM, and DMARC. GMP provides a modern, interoperable method for organizations to protect against impersonation, deepfake-based fraud, unauthorized content changes, and spoofed internal communications in enterprise environments. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | SRv6 Path Egress Protection |
| |
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. The solution uses IGP extensions and a Mirror SID (End.M) behavior to steer traffic to a protector egress upon failure of the primary egress. This document operates within a single link-state IGP area/level and uses IS-IS/OSPFv3 to advertise a Mirror SID and the protected locators for egress node/link protection. While the mechanism can protect traffic whose active segment at the egress is a Service SID (e.g., VPN SID), it is not suitable for large-scale deployments with a high cardinality of VPN/service instances or random multi-homing patterns, because the amount of egress-protection information to be flooded in the IGP increases and may impact convergence and control- plane load. |
| | Change Publication Server used by an RPKI CA |
| |
|
This document outlines how an RPKI CA can migrate from one RFC 8181 Publication Server to another. The process is similar to the RPKI CA Key Rollover process defined in RFC 6489, except that in this case a new location is used for the new key. |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| |
|
| |
| | A Vocabulary For Expressing AI Usage Preferences |
| |
|
This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. |
| | A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths |
| |
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | 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 recommends that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance for how recursive DNS resolvers should select upstream DNS servers, if synthesized and non-synthesized IPv6 addresses are available. This document obsoletes RFC 3901. (if approved) |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical flaws that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. |
| | CMSF- a CMAF compliant implementation of MOQT Streaming Format |
| |
|
This document updates [MSF] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to MSF. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-17.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. The solution specified in this document addresses the requirements for In-stack network action and In-stack data found in RFC 9613. This document follows the architectural framework for the MNA technologies specified in RFC 9789. |
| | SRv6 Bitmap Multicast |
| |
|
Multicast forwarding in a network provides advantages in improving the network usage and performance. In some cases it helps improve the operations in managing network. The major challenge in multicast operations is in managing the per-flow states in the network as required by all the legacy multicast frameworks. This document specifies a bitmap forwarding extension to SRv6 to support state-free forwarding model in a network. |
| | Merkle Tree Certificates |
| |
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-yl-cats-data-model-05.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Huijuan Yao, Changwang Lin, Zhenqiang Li, Quan Xiong, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) systems. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. |
| | Post-Quantum Guidance for current deployments of IETF protocols. |
| |
|
We provide guidance on the use of post-quantum algorithms for those currently deploying applications using IETF protocols with support for such algorithms. |
| | Information Element for Flow Discard Classification |
| |
|
This document defines an IPFIX Information Element for classifying flow-level discards that aligns with the information model defined in [I-D.ietf-opsawg-discardmodel]. The flowDiscardClass Information Element provides consistent classification of packet discards across IPFIX implementations, enabling correlation between device, interface and control-plane discards and the impacted flows. |
| | Instance Information for SDF |
| |
|
This document discusses types of Instance Information to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf) and will ultimately define Representation Formats for them as well as ways to use SDF Models to describe them. // The present revision –07 adds an experimental section on linking // sdfProtocolMap and sdfContext which has been yet another result of // the discussions that happened during and after IETF 124. |
| | EVPN-Specific BMP RIB Statistics Extensions |
| |
|
This document defines new EVPN-specific BGP Monitoring Protocol (BMP) statistics types. These extensions include scalar counters for EVPN route types specifically, while also keeping scope for defining counters which are EVPN route-type agnostic but related to BGP-EVPN RIB like, number of multihoming Ethernet Segments, number of multihomed EVIs, number of aliased paths, number of dynamic inter-VRF route leaking (IVRL). |
| | CMSF- a CMAF compliant implementation of MOQT Streaming Format |
| |
|
This document updates [MSF] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to MSF. |
| | BGP Deterministic Path Forwarding (DPF) |
| |
| | draft-wang-idr-dpf-00.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Kevin Wang, Michal Styszynski, W. Lin, Mahesh Subramaniam, Thomas Kampa, Diptanshu Singh |
| | Working Group: |
Individual Submissions (none) |
|
Modern data center (DC) fabrics typically employ Clos topologies with External BGP (EBGP) for plain IPv4/IPv6 routing. While hop-by-hop EBGP routing is simple and scalable, it provides only a single best- effort forwarding service for all types of traffic. This single best-effort service might be insufficient for increasingly diverse traffic requirements in modern DC environments. For example, loss and latency sensitive AI/ML flows may demand stronger Service Level Agreements (SLA) than general purpose traffic. Duplication schemes which are standardized through protocols such as Parallel Redundancy Protocol (PRP) require disjoint forwarding paths to avoid single points of failure. Congestion avoidance may require more deterministic forwarding behavior. This document introduces BGP Deterministic Path Forwarding (DPF), a mechanism that partitions the physical fabric into multiple logical fabrics. Flows can be mapped to different logical fabrics based on their specific requirements, enabling deterministic forwarding behavior within the data center. |
| | Updates to OAuth 2.0 Security Best Current Practice |
| |
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
| |
|
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. Segment Routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) paths. Furthermore, PCEP can be used to allow a PCE to compute SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR paths (one in each direction in the network) into a single associated bidirectional SR path. The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE- initiated and PCC-initiated LSPs. |
| | The Internet Standards Process |
| |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-07.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| | SSH Agent Protocol |
| |
|
This document specifies a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. |
| | TCP ACK Rate Request Option |
| |
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. |