Recent RFCs

RFC 10080: Updated Use of the Expires Message Header Field

Fri, 30 Oct 2026 00:00:00 GMT

This document allows broader use of the "Expires" message header field for mail messages. Message creators can then indicate when a message expires, while recipients can use this information to handle an expired message differently.

RFC 10078: Problem Statement, Gap Analysis, and Requirements for Intra-Domain Source Address Validation

Fri, 30 Oct 2026 00:00:00 GMT

Source Address Validation (SAV) is an important means to mitigate IP source address spoofing (RFC 2827). This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide.

RFC 10075: The SNAC Router Flag in ICMPv6 Router Advertisement Messages

Thu, 29 Oct 2026 00:00:00 GMT

This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by Stub Network Auto-Configuring (SNAC) routers from information sent by transit routers.

RFC 10051: Task Extensions to iCalendar

Wed, 28 Oct 2026 00:00:00 GMT

The "VTODO" calendar component in the Internet Calendaring and Scheduling Core Object Specification (iCalendar; RFC 5545) has seen limited adoption and use, mainly for personal reminders and to-do lists.

This document updates RFC 5545 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 behaviors.

RFC 10067: Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs

Mon, 26 Oct 2026 00:00:00 GMT

Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs.

PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) where a path in each direction in a network is grouped into an associated bidirectional LSP. This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs.

RFC 10066: Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information

Mon, 26 Oct 2026 00:00:00 GMT

This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP and are designed to be reusable for future path types. Their primary application is Segment Routing Policy (SR Policy), where a Candidate Path can contain multiple segment lists: current PCEP extensions for SR Policy only allow signaling of a single segment list per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load balancing across paths.

RFC 10055: Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms

Wed, 14 Oct 2026 00:00:00 GMT

Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms.

This document provides a snapshot of the ECN state of affairs as supported by these platforms at the time of writing. Readers should refer to the documentation of the various platforms for more up-to-date information.

RFC 10065: A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control

Wed, 07 Oct 2026 00:00:00 GMT

This document defines a YANG data model for policy-based network access control, which enables enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement.

Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism that eases the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, this document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information.

RFC 10054: Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements

Tue, 06 Oct 2026 00:00:00 GMT

Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute-intensive and delay-sensitive services. To optimize throughput and response time, Computing-Aware Traffic Steering (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain and drives requirements for the CATS framework.

RFC 10053: A Framework for Computing-Aware Traffic Steering (CATS)

Tue, 06 Oct 2026 00:00:00 GMT

This document describes a framework for Computing-Aware Traffic

Steering (CATS). Specifically, the document identifies a set of CATS

functional components, describes their interactions, and provides

illustrative workflows of the control and data planes. The framework

covers only the case of a single service provider.

RFC 10049: Roughtime: A Protocol for Rough Time Synchronization

Mon, 05 Oct 2026 00:00:00 GMT

This document describes Roughtime, an experimental protocol that aims to achieve two things: secure, rough time synchronization (even for clients without any idea of what time it is) and a format for clients to report any inconsistencies they observe between timeservers. This document specifies the on-wire protocol required for these goals and discusses aspects of the ecosystem needed for it to work.

RFC 10052: Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)

Wed, 30 Sep 2026 00:00:00 GMT

This document defines an optional extension to the Simple Two-way Active Measurement Protocol (STAMP) that enables a Session-Reflector to send asymmetrical packets, that is, response packets whose size or quantity differs from those sent by the Session-Sender. While standard STAMP exchanges are symmetrical, certain measurement scenarios benefit from reflected packets of different lengths or additional responses to better approximate application traffic conditions. The extension specifies the Reflected Test Packet Control TLV and associated procedures, analyzes challenges in active performance measurement (including in multicast environments), and describes STAMP behaviors to improve measurement efficiency and reduce network impact.

RFC 10050: Protocol-Specific Profiles for JSContact

Sat, 19 Sep 2026 00:00:00 GMT

This document defines the "JSContact Profiles" registry, an IANA registry for named subsets of JSContact elements. The document aims to facilitate using JSContact in the context of contact data exchange protocols or other use cases in which supporting all JSContact semantics might be inappropriate.

RFC 10041: Advertising Unreachable Links in OSPF

Fri, 18 Sep 2026 00:00:00 GMT

OSPF Router Link State Advertisements (LSAs) use fixed-format encodings that always include advertised links in the default Shortest Path First (SPF) computation. For non-default SPF computations, e.g., Flexible Algorithms as described in RFC 9350, advertised OSPF links are used in the default SPF computation even if this is not intended. 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. If all OSPF routers in an OSPF area support this functionality and have advertised the capability via an area-scoped OSPF Router Information LSA, then links advertised with a metric of LSLinkInfinity are considered unreachable.

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, RFC 8379, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff).

RFC 10032: The AEGIS Authenticated Encryption Algorithms

Fri, 18 Sep 2026 00:00:00 GMT

This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption with associated data (AEAD) algorithms designed for high-performance applications. It also specifies their use as stream ciphers and message authentication codes (MACs).

The document is a product of the Crypto Forum Research Group (CFRG).