| |
|
| |
| | OSPF-GT (Generalized Transport) |
| |
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. |
| | Adding a Wrong Recipient URL for Handling Misdirected Emails |
| |
|
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. About This Document This note is to be removed before publishing as an RFC. Discussion of this document takes place on the MAILMAINT Working Group mailing list (mailto:mailmaint@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mailmaint/. Subscribe at https://www.ietf.org/mailman/listinfo/mailmaint/. Source for this draft and an issue tracker can be found at https://github.com/dweekly/ietf-wrong-recipient. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) or Link Layer Discovery Protocol (LLDP) in Software-Defined Networking (SDN). In a traditional Software-Defined Networking, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | IP Payload Compression excluding transport layer |
| |
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. |
| | Segment Routing Policy-Based Source Address Validation (SAV) Mechanism |
| |
|
This draft proposes a novel mechanism for Source Address Validation (SAV) message propagation based on Segment Routing policies (SR- policy). Traditional SAV mechanisms often rely on routing tables (RIB) and Policy-Based Routing (PBR), but these methods lack the flexibility and granularity needed for some network environments. By leveraging the flexibility and control capabilities of SR-policy, the proposed mechanism ensures that SAV messages are propagated along well-defined paths, ensuring efficient, secure, and accurate source address validation. |
| | BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects |
| |
|
The Route Path Authorizations (RPA) is an RPKI object that attests to the routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. |
| | IETF In Memoriam 2025 |
| |
|
The primary purpose of this memo is to remember substantial contributors to the Internet Engineering Task Force who have passed away in the year 2025. Some substantial contributors who died in prior years are also recognized. This memo is NOT a general memorial notice for the broader Internet community. Rather it is centered on persons who made notable contributions to IETF. This memo is NOT the product of any IETF or IRTF working group. It is published in the Independent RFC Stream consistent with guidelines in RFC4846. |
| |
|
| |
| | MUD-Based RATS Resources Discovery |
| |
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. |
| | SMTP Service Extension for Client Identity |
| |
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as SMTP authentication have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of authenticated SMTP activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the SMTP service protocol called "CLIENTID" that a SMTP client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identify verification method in a similar manner to other Multi-Factor authentication techniques. |
| | IMAP Service Extension for Client Identity |
| |
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as [IMAP] have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of [IMAP] activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the [IMAP] service protocol called "CLIENTID" that an [IMAP] client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identity verification method in a similar manner to other Multi-Factor authentication techniques. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | SOUTH: Stochastic Authorization for Agent and Service Requests |
| |
|
SOUTH defines an authorization protocol for evaluating requests issued by users, services, or autonomous agents. SOUTH allows a server to return a deterministic decision or an allow decision that is issued with a probability determined by local policy. This enables servers to incorporate uncertainty, contextual information, and load conditions into authorization decisions. SOUTH is transport independent and can be composed with existing authentication mechanisms such as OAuth, OpenID Connect, mutual TLS, or DPoP. This document describes the request and response objects, decision semantics, and an HTTP binding for interoperable deployment. |
| | Traceroute Framework |
| |
|
This draft introduces the development and latest situation of Traceroute, which is beneficial for network operators and users to understand the latest capabilities of traceroute, enabling them to utilize traceroute effectively. |
| |
|
| |
| | BGP Extensions for the Mobile User Plane (MUP) SAFI |
| |
| | draft-ietf-bess-mup-safi-00.txt |
| | Date: |
25/11/2025 |
| | Authors: |
Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. |
| | Applications and Procedures for Unknown MAC Route in EVPN |
| |
|
The Interconnect Solution for Ethernet VPN defines Unknown MAC (Media Access Control) Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is used as an overlay network for such interconnects. The use of UMR has implications for EVPN MAC mobility procedures, for EVPN L2 and IRB operations, and for EVPN Proxy ARP/ND operations. This document describes additional enhancements required to EVPN procedures and operations when using UMR. This document updates RFC9014 to clarify and extend the proceduresfor UMR usage. |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | Enhanced AS-Loop Detection for BGP |
| |
|
Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. |
| | MSYNC |
| |
| | draft-bichot-msync-19.txt |
| | Date: |
25/11/2025 |
| | Authors: |
Sophie Bale, Remy Brebion, Guillaume Bichot |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. |
| | Compressed SID (CSID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. |
| | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 9231. |
| | Applicability of Computing-Aware Traffic Steering to Intelligent Transportation Systems |
| |
|
This document describes the applicability of Computing-Aware Traffic Steering (CATS) to Intelligent Transportation Systems (ITS). CATS provides the steering of packets of a traffic flow for a specific service request toward the corresponding service instance at an edge computing server at a service site. CATS are applicable for Computing-Aware ITS including (i) Context-Aware Navigation Protocol (CNP) for Terrestrial Vehicles and Unmanned Aerial Vehicles (UAV), (ii) Edge-Assisted Cluster-Based MAC Protocol (ECMAC) for Software- Defined Vehicles, and (iii) Self-Adaptive Interactive Navigation Tool (SAINT) for Cloud-Based Navigation Services, and (iv) Cloud-Based Drone Navigation (CBDN) for Efficient Drone Battery Charging. |
| | Distributed Micro Service Communication architecture based on Content Semantic |
| |
|
This draft introduces a novel communication architecture, called Distributed Micro Service Communication architecture (DMSC). It includes multiple aspects of microservice communication, such as service registration, service discovery, service routing, service scheduling, and more , Which to achieve all the essential functionalities provided by current centralized service networks. By incorporating content-semantic communication, DMSC significantly enhances the performance, scalability, and reliability of microservice communication. It provides a robust architecture for managing the complex communication requirements of distributed microservices, ensuring data integrity, security, and efficient resource utilization. Furthermore, DMSC provides a reference direction for the transition of the service mesh infrastructure from a location-based model to a content- and service-centric paradigm. |
| | Intra-Domain On-Demand Source Address Validation(SAV) Mechanism |
| |
|
Source Address Validation (SAV) mechanisms, such as uRPF, ACLs, and BM-SPF, are applied to prevent IP source address spoofing. However, these mechanisms are typically designed for static routing scenarios and deployed at fixed network boundaries. With the increasing adoption of dynamic forwarding technologies such as SRv6 Policy and Fast Reroute (TI-FRR), the network's actual forwarding path may change frequently due to policy-based traffic steering or link failures. In such cases, statically deployed SAV rules may fail to validate traffic on newly activated or alternate paths, creating validation blind spots or even leading to false positives that block legitimate traffic. This draft proposes an On-Demand Source Address Validation Activation mechanism. It enables routers to dynamically activate or update SAV rules on specific interfaces only when the interface becomes part of an active forwarding path due to policy or failover triggers. This approach enhances SAV coverage, avoids unnecessary resource consumption, and ensures SAV correctness under dynamic path switching scenarios driven by SRv6-policy and TI-FRR. |
| | The DNS XFR URI Schemes |
| |
|
The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred. |
| | Service Status Resource Format for Web Services |
| |
|
This specification defines a standard JSON format for service status resources. It provides a machine-readable format for overall service health indicators, component-level status information with criticality classification, geographic scope identification, and structured incident reporting. This standard enables interoperability between status monitoring tools and service providers. |
| | NTP Over PTP |
| |
|
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers that can timestamp only PTP messages and enables delay corrections in PTP transparent clocks. |
| | Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. |
| | SRv6 Policy SID List Optimization |
| |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes. In some use cases, an SRv6 Policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies procedures to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| |
|
| |
| | BGP Flow Specification for SRv6 |
| |
| | draft-ietf-idr-flowspec-srv6-08.txt |
| | Date: |
24/11/2025 |
| | Authors: |
Zhenbin Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, Shunwan Zhuang |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. |
| | OpenPGP Web Key Directory |
| |
|
This specification describes a service to locate OpenPGP and LibrePGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. |
| | Terminal-based joint selection and configuration of MEC host and DETNET-RAW network |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | Extensions to enable wireless reliability and availability in multi-access edge deployments |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | MIPv6 DETNET-RAW mobility |
| |
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| | QoE-Driven Application-Transport Cooperation Requirements |
| |
|
This document specifies requirements for a QoE-driven transport system, which enables network stack to adjust its transport strategy according to the QoE intent expressed by applications. The Application Layer MUST provide a structured QoE Intent Signal detailing performance objectives to the transport layer. A QoE Mapping Engine is required to translate this intent into adaptive transport strategies. The Transport Protocol Stack SHOULD continuously feed a Transport Feedback Signal on current performance and network status back to the Application Layer, thereby closing the control loop essential for continuous QoE optimization. |
| | QUIC Over Reliable Transport |
| |
|
This document defines QUIC operations when using an underlying reliable transport that, in contrast to UDP, can provide lossless in- order delivery of QUIC packets. The reliable transport may, for example, be TCP or SCTP or a reliable link such as that provided by the 5G radio link protocol. |
| | AI-Native Network Protocol (AINP) for Semantic Agent Communication |
| |
|
This document specifies the AI-Native Network Protocol (AINP) version 0.1, a semantic communication protocol designed for intent exchange between AI agents. AINP replaces location-based routing with semantic routing, byte-stream delivery with intent delivery, and simple handshakes with multi-round negotiation. AINP enables agents to discover each other by capability rather than network location, negotiate terms autonomously, and exchange structured intents with cryptographic security. |
| | HTTP Agent Profile (HAP): Authenticated and Monetized Agent Traffic on the Web |
| |
|
Autonomous agents such as LLM-powered crawlers, browser-integrated assistants, and task-oriented bots are rapidly becoming first-class HTTP clients on the Web. Today’s infrastructure largely assumes a human behind a browser and monetizes content through advertising and coarse subscriptions. Automated agents consume content at scale without rendering pages or viewing ads, exacerbating bot-mitigation arms races and economic misalignment between content providers and AI systems. This document describes an HTTP Agent Profile (HAP) that enables: (1) cryptographic authentication of agent traffic using HTTP Message Signatures; (2) clear separation between human and agent traffic using privacy-preserving human tokens; and (3) protocol-level value exchange for agents via HTTP status code 402 ("Payment Required") and pluggable micropayment mechanisms. The profile reuses existing HTTP features and is designed for incremental deployment via reverse proxies, CDNs, and agent libraries. |
| |
|
| |
| | Advertising Flexible Algorithm Extensions in BGP Link-State |
| |
|
Flexible Algorithm is a solution that allows some routing protocols (IS-IS and OSPF) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by IS-IS and OSPF flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. |
| | Supporting In Situ Operations,Administration and Maintenance Using MPLS Network Actions |
| |
| | draft-ietf-mpls-mna-ioam-04.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Rakesh Gandhi, Greg Mirsky, Tony Li, Haoyu Song, Bin Wen |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and record the operational state and telemetry information using, for example, Pre- allocated, Proof-of-Transit, Edge-To-Edge or Incremental IOAM Options, that can be used to calculate various performance metrics. RFC 9326 defined the IOAM Direct Export (IOAM-DEX) Option in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy on each node along the path. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transfer data needed for these actions. This document explores the MNA mechanisms to collect and transport the on-path operational state, and telemetry information IOAM data fields, including IOAM-DEX Option. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-10.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-09.txt |
| | Date: |
20/11/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | TMCH Functional Specification Update |
| |
|
This document describes updates to the functional specification of the Trademark Clearing House, among them a new verison of the trademark claims notice. |
| | Internet 2.0: An Intent-Aware,AI-Native Extension of the Web |
| |
|
This document proposes Internet 2.0, an AI-native extension of the traditional web architecture. Unlike the current internet—which is designed primarily for document retrieval—Internet 2.0 enables distributed model discovery, intent-based routing, and protocol-level AI interaction. Core components include HTTP+AI, an AI-aware extension to HTTP; the Model Resolution Network (MRN), an AI-native analogue to DNS; and the AI-Aware Browser, a new class of client optimized for intelligent interaction rather than document traversal. This architecture treats AI models as first-class network entities and provides a foundation for a decentralized, semantic, and privacy- preserving AI layer on the internet. |
| | Authenticated Cache-Expiration Opcode (EXPIRE) |
| |
|
This document defines a new DNS message opcode, EXPIRE, which enables an authenticated authoritative operator to request immediate deletion of a specific RRset from a resolver's cache. EXPIRE messages may be authenticated either through DNSSEC signatures or through resolver control-channel authentication (for example TSIG, mutually authenticated TLS, IPsec, or local trust policy). EXPIRE applies only to resolver cache and MUST NOT modify authoritative data. Resolvers validate authority, apply mandatory replay protection using SOA serials when available or equivalent replay-mitigation mechanisms, and flush the targeted RRset upon successful validation. EXPIRE provides a deterministic, authenticated mechanism for cache rollback and correction across both signed (DNSSEC) and unsigned (internal) DNS deployments. |
| |
|
| |
| | Problem Statement and Use Cases of Application-aware Networking (APN) |
| |
|
Network operators are facing the challenge of providing better network services for users. As the ever-developing 5G and industrial verticals evolve, more and more services that have diverse network requirements such as ultra-low latency and high reliability are emerging, and therefore differentiated service treatment is desired by users. On the other hand, as network technologies such as Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep evolving, the network has the capability to provide more fine- granularity differentiated services. However, network operators are typically unaware of the applications that are traversing their network infrastructure, which means that not very effective differentiated service treatment can be provided to the traffic flows. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network satisfying the fine- granularity requirements. This document analyzes the existing problems caused by lack of service awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) framework. |
| | Use cases of Application-aware Networking (APN) in Edge Computing |
| |
|
The ever-emerging new services are imposing more and more highly demanding requirements on the network. However, the current deployments could not fully accommodate those requirements due to limited capabilities. For example, it is difficult to utilize the traditional centralized deployment mode to meet the low-latency demand of some latency-sensitive applications. Moreover, the total amount of centralized service data is growing exponentially, which brings great pressure on the network bandwidth. There has been a clear trend that decentralized sites comprising of computing and storage resources are deployed at various locations to provide services. In particular, when the sites are deployed at the network edge, i.e. the Edge Computing, it can better handle the business needs of the users nearby, which provides the possibilities to provide differentiated network and computing services. In order to achieve the full benefits of the edge computing, it actually implies a precondition that the network should be aware of the applications' requirements in order to steer their traffic to the network paths that can satisfy their requirements. Application-aware networking (APN) aims to accommodate the edge services' needs, fully releasing the benefits of the edge computing. This document describes the various application scenarios in edge computing to which the APN can be beneficial, including augmented reality, cloud gaming and remote control, which empowers the video business, users interaction business and user-device interaction business. In those scenarios, APN can identify the specific requirements of edge computing applications on the network, process close to the users, provide SLA guaranteed network services such as low latency and high reliability. |
| | Use cases of Application-aware Networking (APN) in Game Acceleration |
| |
|
With the development of the Internet, game industry has risen rapidly, from handheld game consoles to PC games and mobile games. The types of games are diversified, while the number of game users is increasing year by year. The game market is maturing quickly. Nowadays, the scale of game users is large and they belong to the easy-to-consume groups. Among all the games, those require frequent interactions and involve video streaming usually have highly demanding requirements on the network in terms of guaranteed network latency and reliability. Therefore, from the aspect of ensuring better gaming experience, it is desirable of differentiating the particular gaming application flows and providing high-priority network services for those demanding gamers. This document describes the game acceleration scenarios using Application-aware Networking (APN) technology. In these scenarios, APN can identify the specific requirements of particular gaming applications, steer the flows to the game processors close to the users, and provide SLA guaranteed network services such as low latency and high reliability. |
| | Usage scenarios of Application-aware Networking (APN) for SD-WAN |
| |
|
This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a application group, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability. |
| | Application-aware Networking (APN) Header |
| |
| | draft-li-apn-header-05.txt |
| | Date: |
12/11/2025 |
| | Authors: |
Zhenbin Li, Shuai Zhang, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the application-aware networking (APN) header which can be used in a variety of data planes. |
| | Extension of Application-aware Networking (APN) Framework for Application Side |
| |
|
The Application-aware Networking (APN) framework defines that application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. This document defines the extension of the APN framework for the application side. In this extension, the APN resources of an APN domain is allocated to applications which compose and encapsulate the APN attribute in packets. When the network devices in the APN domain receive the packets carrying APN attribute, they can directly provide fine-granular traffic operations according to these APN attributes in the packets. |
| | Application Aware Computing Network |
| |
|
This document describes a solution framework that adheres to the CATS framework. The solution uses APN as part of the CATS service identifier and flow identifier. |
| | Application-aware Networking (APN) Framework |
| |
| | draft-li-rtgwg-apn-framework-01.txt |
| | Date: |
12/11/2025 |
| | Authors: |
Zhenbin Li, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. |
| | Application-aware IPv6 Networking (APN6) Encapsulation |
| |
|
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the APN header and its encapsulation in the IPv6 data plane. |
| | Route Origin Registry Problem Statement |
| |
| | draft-jiang-sidrops-psvro-03.txt |
| | Date: |
12/11/2025 |
| | Authors: |
Shenglin(Forrest) Jiang, Ke Xu, Li Qi, Xingang Shi, Zhuotao liu |
| | Working Group: |
Individual Submissions (none) |
|
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin AS (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry. |
| | DS support for private DNSSEC algorithms |
| |
|
Extend the DS digest field of the DS record to identify the private DNSSEC algorithm of the DNSKEY matching the DS record. |
| | Media over QUIC - Hang |
| |
|
Hang is a real-time conferencing protocol built on top of moq-lite. A room consists of multiple participants who publish media tracks. All updates are live, such as a change in participants or media tracks. |
| | APN Scope and Gap Analysis |
| |
|
The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an attribute allowing the implementation of fine-grain user group-level and application group- level requirements in the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, for example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to efficiently realize this composite network service provisioning along the path. This document further clarifies the scope of the APN work and describes the solution gap analysis. |
| | APN Security and Privacy Considerations |
| |
|
Application-aware Networking (APN) aims to convey Application-aware Information (APN attribute) including APN ID and APN parameters indicating application group-level and user group-level requirements along with the data packets into the network and enable the network to provide corresponding fine-granular network services. There have been challenges of the privacy and security issues that could potentially be introduced by conveying the APN attribute into the network. This document describes the security and privacy considerations of APN in various possible scenarios wherein APN will be deployed. |
| | Dissemination of BGP Flow Specification Rules for APN |
| |
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute including APN ID and/or APN Parameters. The dynamic Flow Spec mechanism for APN is designed for the new applications of traffic filtering in an APN domain as well as the traffic control and actions at the policy enforcement points in this domain. These applications require coordination among the ASes within a service provider. This document specifies a new BGP Flow Spec Component Type in order to support APN traffic filtering. The match field is the APN ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsulation when matched to the corresponding Flow Spec rules. |
| | A YANG Model for Application-aware Networking (APN) |
| |
|
Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute (incl. APN ID and/or APN Parameters) to enable fine grained service provisioning. This document defines a YANG module for APN. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | Variable Length Node Data Field Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
|
The purpose of this memo is to describe a new IOAM Node Data Field type, called Flex Field, for In-Situ Operations, Administration, and Maintenance (IOAM). This option type, under IOAM Trace Option-Types will allow one to append variable length node data in an IOAM packet, along a network path. |
| |
|
| |
| | Advertising SID Algorithm Information in BGP |
| |
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. |
| | Architectural Considerations for Environmental Sustainability |
| |
|
This document describes several of the design tradeoffs involved in optimizing for sustainability along with the other common networking metrics such as performance and availability. |
| | Sustainability Considerations for Networking Protocols and Applications |
| |
|
Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementers sustainability- related advice and guidance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. |
| | Environmental Sustainability Terminology and Concepts |
| |
|
This document defines a set of sustainability-related terms and concepts to be used while describing and evaluating the negative and positive environmental sustainability impacts and implications of Internet technologies. |
| | Fixed AES-GCM modes for the SSH protocol |
| |
|
This document describes the use of the AES-GCM AEAD in the Secure Shell (SSH) protocol, using the underlying construction of [RFC5647] but fixing problems in the negotiation mechanism. |
| | Cross-Domain Cloud-Native Resource Orchestration Framework with Dynamic Weight-Based Scheduling |
| |
|
The Distributed Resource Orchestration and Dynamic Scheduling (DRO- DS) standard in cross-domain cloud-native environments aims to address the challenges of resource management and scheduling in multi-cloud architectures, providing a unified framework for efficient, flexible, and reliable resource allocation. As enterprise applications scale, the limitations of single Kubernetes clusters become increasingly apparent, particularly in terms of high availability, disaster recovery, and resource optimization. To address these challenges, DRO-DS introduces several innovative technologies, including dynamic weight-based scheduling, storage- transmission-compute integration mechanisms, follow-up scheduling, real-time monitoring and automated operations, as well as global views and predictive algorithms. |
| | Secure Webhook Token (SWT) |
| |
|
The Secure Webhook Token (SWT) is a specialized JSON Web Token (JWT) format designed for securely authorizing and verifying webhook requests. It defines a set of claims to ensure that the token is explicitly tied to webhook events and that its integrity can be reliably validated by the recipient. A key feature of SWT is the introduction of a unique claim, webhook, which encapsulates webhook- specific information, such as the event type. By providing a structured and secure approach to webhook authentication, SWT aims to be a lightweight and flexible solution while maintaining compatibility with typical JWT structures. It is designed with the best practices in mind and may serve as a foundation for future standardization efforts. |
| | SSH Strict KEX extension |
| |
|
This document describes a small set of modifications to the Secure Shell (SSH) protocol to fix the so-called Terrapin Attack on the initial key exchange. |
| |
|
| |
| | BGP Extension for SR-MPLS Entropy Label Position |
| |
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. |
| | IMAP Extensions Suggestions |
| |
|
This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. |
| | Dangerous Labels in DNS and E-mail |
| |
|
This document establishes registries that list known security- sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. |
| | Asset Schema Architecture for Asset Exchange |
| |
|
A management architecture for asset schemas and profiles is needed to enable entities in the tokenized assets ecosystem to instantiate tokens within one or more asset networks. An asset network may be constrained to support only a select class or type of token to be present in the network. In the SATP protocol, the receiving gateway at the destination network is assumed in its preparatory stages to evaluate the transfer request of a tokenized asset from the sending gateway at the origin network. In order to evaluate the proposed transfer, the receiving gateway must have access to the asset definition schema upon which the token was based in the origin network. The current document discusses the management architecture for the asset definition schema and the schema-profiles derived from the definition schema |
| | Test Battery for Opus ML Codec Extensions |
| |
|
This document proposes methodology and data for evaluation of machine learning (ML) codec extensions, such as the deep audio redundancy (DRED), within the Opus codec (RFC6716). |
| | The 'donau' URI scheme for validation of donation statements. |
| |
| | draft-grothoff-donau-02.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Christian Grothoff, Emmanuel Benoist, Bohdan Potuzhnyi, Florian Dold |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the 'donau' Uniform Resource Identifier (URI) scheme for triggering interactions with a validator for Donau donation statements. This URI scheme allows applications to trigger interactions with a Donau validator. A Donau validator is typically run by a tax authority to validate tax records from citizens that made donations to a charity that supports the Donau protocol. The Donau validator will receive 'donau' URIs representing the sum of donations a taxpayer made to recognized charities over a year. Donors would submit 'donau' URLs (or QR codes with 'donau' URLs) to tax authorities to have their donations recognized by the tax authority as tax-deductible expenditures. The application logic to verify the validity of the donation is triggered by 'donau' URIs. The validator application would then typically confirm to the tax official the validity of the signature encoded in the URI and show the total amount donated as well as the taxpayer identification number and the year of the donation. Multiple URIs could be submitted per donor, and the application can correctly determine which submissions are cumulative and which ones are redundant. This specification only covers the syntax of the 'donau' URI scheme and excludes details on the protocol(s) that would allow taxpayers to donate to recognized charities to obtain these suitable signed donation statements. While a privacy-preserving protocol to obtain such statements exists within the context of the GNU Taler protocol suite, other protocols could be developed in the future and still yield compatible 'donau' URIs as the URI scheme is reasonably generic. The validation tool will be registered for all donau:// URIs. Since each taxation authority will typically use a different domain, it will not be feasible to encode all the domains of tax authorities servers inside the validation tool. Hence a new URI scheme is needed that will trigger the validation tool for any domain name. |
| | Agents Networking Scenarios in Enterprise and Broadband Networks |
| |
|
This document describes agents networking scenarios in enterprise and home broadband networks. These scenarios differ from mobile networks and Internet scenarios. Since the agentic service is still at the emerging stage, especially in enterprise and home broadband networks, the scenarios are mostly based on reasonable assumptions. |
| | AI Agent to Tool (A2T) Protocol |
| |
|
This document defines a protocol that facilitates integration of tools into the design and run-time operations of AI Agents. The focus is on enterprise AI agents that need to make use of APIs exposed by third party providers. This protocol, called the Agent- to-Tool (A2T) Protocol defines an OpenAI spec that has two principle features - enumeration of tools and invocation of tools. The enumeration API enables a human - the AI Agent designer employed by the enterprise - to select and include tools from third-party vendors into operating procedures (also known as skills or instructions) which direct the behavior of AI Agents, including how and when to invoke those tools. The enumeration API can also be used (optionally) at run-time for the LLM to obtain tool descriptions. The second feature of the API - invocation - allows the AI Agent executor to perform the inter-domain invocation of the tool at run time. By standardizing these two API functions, the time and cost of integration of Internet APIs into AI Agents can be reduced. |
| | CDN Node Selection Enhancement using Anycast and QUIC |
| |
|
Content Delivery Networks (CDNs) are critical infrastructure for improving user experience by serving content from geographically proximate servers. Traditional CDN node selection mechanisms, such as DNS-based redirection and BGP-based anycast, primarily rely on network proximity and often lack awareness of server load or specific application requirements. This can lead to suboptimal performance and inefficient resource utilization. This document proposes an enhanced mechanism for dynamic CDN node selection that leverages IPv4/v6 anycast, BGP, and the QUIC transport protocol. The proposed solution enables CDN nodes to advertise or withdraw their anycast routes based on real-time load and link quality. Furthermore, it defines a mechanism for clients to signal their service requirements (e.g., high-compute, low-latency, or high- bandwidth) and for servers to redirect clients to more optimal nodes using QUIC's connection migration capabilities. This allows for a more intelligent, load-aware, and application-aware CDN node selection process. |
| | Discovering x402 Resources via DNS TXT Records |
| |
|
This document defines a DNS-based discovery mechanism for locating x402 payment resources associated with a domain. Domains publish one or more _x402 TXT records containing URLs where x402-compatible clients can obtain resource manifests and metadata over HTTPS. The goal is to provide a lightweight, cache-friendly discovery vector that enables automated payment negotiation using the x402 protocol while keeping DNS records static and non-sensitive. |
| | vCon Zip Bundle |
| |
|
This document defines the vCon Zip Bundle (.vconz) file format for packaging one or more vCon conversation data containers with their associated media files into a single, self-contained ZIP archive. While vCons support external file references via HTTPS URLs with content hashes, these dependencies create availability and portability challenges. The vCon Zip Bundle addresses this through a standardized archive format that includes all referenced files, supports multiple vCons with automatic deduplication based on content hashes, preserves data integrity through hash verification, and enables offline processing. This specification maintains full compatibility with all vCon security forms (unsigned, signed, encrypted) as defined in the vCon core specification. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) |
| |
| | draft-ietf-pce-pcep-nrp-00.txt |
| | Date: |
06/11/2025 |
| | Authors: |
Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad |
| | Working Group: |
Path Computation Element (pce) |
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. |
| | Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs) |
| |
|
This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. This document obsoletes RFC6791, Stateless Source Address Mapping for ICMPv6 Packets and updates IP/ICMP Translation Algorithm (RFC7915). |
| |
|
| |
| | Ownership and licensing statements in YANG |
| |
|
This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | Extension Formatting for the Opus Codec |
| |
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-42.txt |
| | Date: |
05/11/2025 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows |
| |
|
This specification defines the web message response mode that authorization servers use for transmitting authorization response parameters via the user-agent's postMessage API to the client. This mode is intended for authorization flows that use secondary windows, which are well-suited for browser-based applications. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | Advertisement of SR Policy Administative Flags using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | Knowledge Graph for Network Traffic Monitoring and Analysis |
| |
|
This document extends the knowledge graph framework specifically to the traffic management domain, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. |
| | Enhancement for Monitoring VRF's Loc-RIB |
| |
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a VPN route information to zero, and sets the Peer Distinguisher value of a VPN route information to the route distinguisher or unique locally defined value of the particular instance the Loc-RIB belongs to. This document introduces the option to communicate the Remote VRF Information from which a VPN route was received when reporting that VPN route information with BMP Loc-RIB. |
| | Agent Considerations |
| |
|
IETF specifications provide the basis for technical implementation in several programming languages. An IETF specification that provides appropriate guidance to artificial intelligence (AI) agents, can enable such agents to consume specifiction and generate code from it. This documents defines the use of an Agent Consideration section that is in support of code generation including the use of agentcards, guidance on authorship, examples and their annotation for code generation, as well as language specific guidance for the production of media-types. The Agent Consideration defined in this document can be added to any Internet-Draft that includes normative language and sufficiant expressive examples derived from an included data model and protocol interaction defintions. |
| | Using MUD in Constrained Environments |
| |
|
This document specifies additional ways for discovering and emitting Manufacturer Usage Descriptions (MUD), especially in constrained environments, utilizing the Constrained Application Protocol (CoAP), CoRE Resource Discovery, and CBOR Web Tokens. |
| | Passive Hot Reload for Web Servers |
| |
|
This document defines a passive, file-based mechanism for automatic hot reloading of configuration files and TLS certificates in web servers. Unlike traditional web servers that require explicit reload commands, this design uses file modification time (mtime) to detect changes and reloads in memory automatically. |
| | Age Verification Architecture |
| |
| | draft-knodel-age-arch-00.txt |
| | Date: |
05/11/2025 |
| | Authors: |
Mallory Knodel, Gianpaolo Scalone, Thomas Newton |
| | Working Group: |
Individual Submissions (none) |
|
This document describes solution-agnostic and technology-neutral schema for how various intermediaries can gate content and services based on age. The analysis of the architecture is done based on the effectiveness of permitting or restricting access based on age. The document concludes with recommendations as well as critical privacy, security and human rights considerations. |
| | Remote Attestation for Trustworthy Workload Identity |
| |
|
Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy Workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. |
| |
|
| |
| | Encrypted DNS Server Redirection |
| |
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. |
| | Multiple Loss Ratio Search |
| |
|
This document describes an alternative to "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) throughput by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and improve result repeatability and comparability. MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software-based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs purpose-built ASIC / NPU / FPGA hardware. |
| | Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE |
| |
|
This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tplooker/draft-ietf-cose-bls-key-representations. |
| | REST API Media Types |
| |
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | Mail Autoconfig |
| |
|
A protocol that allows email applications to set up mail accounts and related accounts with only the email address and password. It defines how service providers can publish the account configuration, so that email applications can automatically find a working configuration. It reduces setup friction for their users, and calls to the support for the service provider. Although the discovery process starts with an email address, the protocol is not limited setting up email accounts, but can also set up calendar, contact and file sync, video conference accounts and other accounts that are connected to the same user account. This protocol uses a well-known address and DNS lookups, based on the email address domain, to find the XML configuration file for the service provider. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | RADIUS over QUIC |
| |
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. |
| | A reference architecture for direct presentation credential flows |
| |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. |
| | LDP Extensions for Flex-Algo |
| |
|
This document specifies extensions to LDP to support the use Flex- Algo, enabling Label Switched Paths (LSPs) to follow a specific Flex-Algo. |
| | SCIM RoleAssignment Draft Specification v0.2 |
| |
|
SCIM 2.0 defines "roles" and "entitlements" attributes on the User resource, but it lacks a standardized way to bind roles to specific scopes such as projects, tenants, or groups. This gap forces organizations to rely on group sprawl or non-standard encodings, preventing true interoperability. This document introduces a new SCIM resource type, RoleAssignment, which models scoped role bindings as first-class records, enabling portable provisioning, lifecycle governance, and compliance visibility. |
| | NTPv5 Algorithms |
| |
|
This document describes considerations of synchronisation algorithms with version 5 of the Network Time Protocol (NTP), and provides guidance on the use of NTP version 4's algorithms when used with NTP version 5. |
| | A CBOR Tag for Lossless Transport of IEEE-754 NaN Bit Patterns |
| |
|
IEEE-754 NaN formations are not numbers and have no equivalence class. They are not comparable to anything, including reflexively, and therefore each attribute - sign bit, signaling/quiet bit, payload bits, and representation width (binary16, binary32, binary64, binary128) - can carry meaning for an implementation. CBOR permits encoding NaNs as floating-point values, but generic processing, preferred serialization, and deterministic profiles may canonicalize or otherwise alter NaN encodings, losing information. This document defines a CBOR tag, colloquially "nan-bstr", whose content is a byte string carrying the exact IEEE-754 NaN bit pattern so that all attributes are preserved across encode/decode, enabling use cases like NaN boxing, platform-specific error signaling, diagnostics, and forensics. |
| | SONAR: Statistical Observation Network for Attestation and Reach |
| |
|
This document specifies SONAR (Statistical Observation Network for Attestation and Reach), a protocol for verifiable multicast delivery claims without trusted intermediaries. SONAR combines: (1) O(1) IP multicast efficiency versus O(N) unicast to detect cheating, (2) cryptoeconomic accountability via on-chain stake deposits, VRF-based unpredictable sampling, and blockchain attestations, and (3) ALTA- based real-time multicast authentication. SONAR separates content authentication from coverage verification: ALTA authenticates all packets with ~6% bandwidth overhead, while statistical coverage verification adds minimal overhead (320 KB challenge messages per 15-60 minute test period, 0.7-2.8 Kbps). Coverage estimation samples 0.1% of receivers using German Tank Problem inference. For privacy and cost efficiency at scale, zkSNARK proof aggregation (recommended for >1,000 sampled users) maintains O(1) on-chain verification cost, enabling populations exceeding 10^8 receivers. |
| | Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) |
| |
|
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using, the forthcoming, FIPS 206, the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | Use of the FN-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), as defined by NIST in FIPS 206, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the FN-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier is provided. |
| | A reference architecture for direct presentation credential flows |
| |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. |
| | BPP |
| |
|
This document defines the Bitcoin Price Protocol (BPP), a lightweight, peer-to-peer protocol for synchronising a high-confidence Bitcoin price across untrusted networks. Modeled after the Network Time Protocol (NTP, RFC 5905), BPP enables any Internet host to obtain a volume-weighted median USD/BTC price that is accurate to within a few dollars and fresh to within a few seconds, without trusting any single exchange, oracle, or API provider. BPP is deliberately off-chain, runs over UDP/QUIC, and requires no blockchain interaction. It is suitable for wallets, trading bots, payment processors, DeFi front-ends, and hardware devices that need "NTP-grade" price agreement. |
| | The ipn.arpa Zone and IPN DNS Operations |
| |
|
This document requests a DNS parent for IPN addresses, discusses the registration procedures and management of the DNS zone, as well as some operational recommendations. This document specifies that IPN addresses may have a DNS representation of the form 1.978879.ipn.arpa, for IPN node 1 under IPN Allocator 978879. This document also describes how this DNS structure can be useful in locating the Bundle Protocol (BP) Convergence Layer (CL) endpoint(s) of the BP Agent responsible for a given IPN address. |
| |
|
| |
| | RTP Payload Format for V-DMC |
| |
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-21.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-19.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | DKIM2 Header Definitions |
| |
|
This document describes the email header fields defined for DKIM2, and how they work togther to provide the required properties. This is an early draft, a work in progress. |
| | A method for describing changes to emails |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. This method also captures hashes of important features of the message, allowing validation that the changes were described correctly, and allowing a signature which covers the Mail-Version header to, by extention, ensure that the important content of the message is unchanged. |
| | Intimate Partner Violence Digital Considerations |
| |
| | draft-irtf-hrpc-ipvc-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Sofia Celi, Juliana Guerra, Mallory Knodel |
| | Working Group: |
Human Rights Protocol Considerations (hrpc) |
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These security compromises go beyond active and passive on-path attacks [RFC7624]. With a focus on protocols, the document describes tactics of the IPV attacker and potential counter-measures. |
| | LISP Virtual Private Networks (VPNs) |
| |
| | draft-ietf-lisp-vpn-13.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. |
| | CARP - a CMAF compliant implementation of WARP |
| |
|
This document updates [WARP] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to WARP. |
| | External Trace ID for Configuration Tracing |
| |
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using SCONE protocol signalling, it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | User Attributes in OpenPGP |
| |
|
This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. |
| | Requirements Analysis of System and Network for Large Language Model Inference Service |
| |
|
With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, such as vLLM, SGLang, Mooncake, etc. This paper investigates mainstream inference frameworks, summarizes their core design principle and research question, and analyzes the challenges and requirements they impose on network management. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. |
| | Fragmentation Revisited: For What It's Worth |
| |
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. |
| | Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors |
| |
|
ICMP error messages are vital for network reliability, providing feedback on issues such as unreachable hosts or fragmentation requirements. They help devices adapt dynamically, support troubleshooting, and enable essential functions like Path MTU Discovery. However, off-path attackers on the Internet may forge ICMP error messages to bypass legitimate validation mechanisms, causing the victim's TCP/IP stack to misinterpret network conditions and exposing critical vulnerabilities. This document analyzes how such forged ICMP errors can be exploited by off-path attackers to induce cross-layer interactions within the victim's TCP/IP stack, leading to four classes of vulnerabilities: information leakage, desynchronization of shared variables, semantic gaps, and identity deception. These ICMP-based attacks allow off-path attackers to manipulate network traffic, disrupt communication flows, and compromise both infrastructure and user privacy, without being on the direct communication path. The document concludes with proposed countermeasures and recommendations for protocol evolution. |
| | DACP: Data Access and Collaboration Protocol |
| |
| | draft-shenzhihong-dacp-01.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Zhihong Shen, Xiaojie Zhu, Zhenjing CHENG, Ziang Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Data Access and Collaboration Protocol (DACP), a communication protocol designed to support cross-node, cross-process data access in scientific and distributed computing environments. DACP provides standardized streaming-based data interactions over the Arrow Flight protocol and defines a unified Streaming DataFrame (SDF) model, which acts as a high-performance abstraction for accessing and processing both structured and unstructured data. |
| | Generic Event Notification (GEN) for BGP Monitoring Protocol (BMP) |
| |
|
This document defines a new BMP message type: the Generic Event Notification (GEN). The BMP GEN message provides a flexible mechanism for reporting a wide variety of events related to BGP at different levels of hierarchy, such as routing instance, AFI/SAFI, or peer level. The BMP GEN message enables operators and automated systems to receive detailed context for operational events, such as policy triggers, administrative interventions, and state management notifications (e.g., RIB view unmonitor events). |
| | Agent Identity Managenment |
| |
|
This document specifies agent identity management in the Internet of Agents (IOA) system. It defines the descriptive requirements for agent identities, the agent registration process, the structure and assignment of agent identifiers, and the basic and extended identity management functions performed by the agent gateway based on the agent's descriptive information. |
| | Agents Networking Framework for Enterprise and Broadband |
| |
|
This document introduces agents networking framework and defines the core components of agent networking in enterprise and broadband, as well as typical interactions among these key components. |
| | External Relationship model for SIMAP |
| |
|
This document defines a SIMAP feature that enables modeling of external relationships between SIMAP entities and resources outside their core data models. It provides a templating approach to describe queries for external information, and an approach to link them to network elements. |
| | Scrubbing BGP ORIGIN Attribute |
| |
|
The BGP Origin attribute in its original meaning has been out of use for years. Yet, the BGP Origin attribute has high priority in the best route selection algorithm, right after the AS Path length, and it's being used inconsistently over the Internet to manipulate the route preference. This document updates RFC 4271 and RFC 7606 by making the BGP Origin attribute half-optional and explicitly allowing its scrubbing to zero (IGP). |
| | Phishing-Resistant Phone Number Attestation for MFA |
| |
|
This draft introduces a phishing-resistant phone number attestation mechanism for multi-factor authentication (MFA). Conceptually similar to WebAuthn, it uses origin-bound cryptographic challenges to ensure that users only attest ownership of their phone numbers to legitimate relying parties. The protocol leverages network-operator- issued verifiable credentials (VCs) that cryptographically bind phone number ownership to a user's device. Applications present origin- scoped challenges that users sign using their VC, ensuring secure, domain-specific authentication and mitigating replay, relay, and phishing attacks- without relying on SMS-based one-time passwords (OTPs). |
| | Semantic Routing Architecture for AI Agents Communication |
| |
|
This document introduces an Semantic Routing (SR) Architecture for enabling intelligent, semantic-driven communication among AI Agents. Unlike traditional IP-based routing or service mesh approaches, SRA leverages application-layer semantics — including service identity, intent vectors, and trust scores — to guide routing decisions dynamically. The architecture supports intent-driven task collaboration, trust-aware policy enforcement, and adaptive routing for multi-agent environments. SRA enables the network to evolve from a passive transport layer to an intelligent collaboration substrate supporting multi-agent coordination and cognitive networking. |
| | Routing Architecture for Satellite Networks Based on Hierarchical Structure |
| |
|
The satellite routing is the premis to ensure that the satellite network provides end-to-end stable service covering the whole globe. However, the mature terrestrial network technologies are difficult to directly apply to the satellite network because of the highly dynamic network topology and the limited on-board resources. In view of this challenge, this document presents a hierarchical routing architecture for satellite networks based on the prediction topology between satellites or satellites and ground stations. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-02.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-12.txt |
| | Date: |
03/11/2025 |
| | Authors: |
Ahmed Abdelsalam, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |