| |
|
| |
| | 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. |
| |
|
| |
| | JMAP Mail Sharing |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) for Mail to enable sharing of mailboxes between users. Building upon the JMAP Sharing framework defined in [RFC9670], this specification extends the Mailbox data type defined in [RFC8621] with properties necessary to configure and manage access permissions for shared mailboxes. The extension introduces a new capability that indicates server support for mailbox sharing and defines the additional properties required to share mailboxes with other principals, including the ability to control which users may access a mailbox and what permissions they possess. |
| | CBOR Simple Value for CSF |
| |
|
This document defines two CBOR "simple" values to be used as unique labels in a CBOR map holding an embedded signature. |
| | The Web of Agents (WoA) |
| |
|
This document defines the Web of Agents (WoA), a minimal JSON based description format and invocation convention that allows HTTP hosts to advertise AI agents and for clients to invoke those agents in a uniform way. A WoA document is typically served from a well known location on an HTTP origin and uses JSON Schema to describe agent inputs and outputs. WoA does not define a discovery protocol itself but is designed to be used as a host level primitive by higher level discovery systems. |
| | Agent Persistent State Profile |
| |
|
Autonomous agents increasingly maintain durable persistent state containing user preferences, embedding vectors, safety logs, intermediate reasoning steps, and audit traces. Today, agent frameworks treat storage as a generic file system, while storage administrators treat agents as stateless virtual machines. This "layer mismatch" leads to fragility, poor performance, and privacy risks. The Agent Persistent State (APS) Profile defines an experimental, vendor-neutral storage service class for durable agent state. APS emphasizes *compliance*: ensuring that memory associated with a specific user or agent identity can be retained, audited, and cryptographically erased. APS also addresses high-frequency small I/ O, vector index workloads, crash consistency, and Kubernetes/CSI [CSI] integration. APS introduces a Usage Class ("AgentPersistentState"), a versioned PersistentStateLineOfService schema, guidance for container orchestration systems, non-normative bindings for Swordfish [Swordfish] and Redfish [Redfish], and considerations for multi- tenancy. APS is intended as an Experimental RFC to gather implementation feedback prior to any standards-track work. |
| |
|
| |
| | MUD-Based RATS Resources Discovery |
| |
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. |
| | 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. |
| |
|
| |
| | Requirements for Agent Gateway |
| |
|
This document discusses the requirements for introducing Agent Gateways into Agent-to-Agent communications for better scalability, communication efficiency, and security etc. This document also discusses the gaps of current hardware/software gateways that could not fulfil the task, so that a new kind of entity, e.g. Agent Gateway, is needed. |
| | Enhanced A2A Requirements for Agents Collobration in Enterprise |
| |
|
This document proposes enhanced requirements for the A2A protocol tailored to enterprise applications. |
| | Mail Pre-Flight Template Discovery Protocol (MPTDP) |
| |
|
This document specifies the Mail Pre-Flight Template Discovery Protocol (MPTDP). This mechanism allows a Mail User Agent (MUA) to proactively discover and retrieve a structured message template based on the recipient's public email address, prior to message composition. It utilizes a well-known URI structure and provides a security manifest to prevent address enumeration. |
| | SRv6 for Inter-Layer Network Programming |
| |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| |
|
| |
| | MISP core format |
| |
|
This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. |
| | Intel Profile for Remote Attestation |
| |
| | draft-cds-rats-intel-corim-profile-06.txt |
| | Date: |
26/11/2025 |
| | Authors: |
James Beaney, Yogesh Deshpande, Andrew Draper, Vincent Scarlata, Ned Smith, Francisco Chinchilla |
| | Working Group: |
Individual Submissions (none) |
|
This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes a particular application of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers. |
| | OAuth Trust Binding Extension (OTBE) |
| |
|
This document defines the OAuth Trust Binding Extension (OTBE), a mechanism allowing Resource Owners to explicitly authorize which Authorization Servers may assert their identity towards Relying Parties, mitigating silent impersonation and namespace-based identity capture. |
| | ASN Prefix-based Addressing for IPv6 |
| |
|
This document describes a method and policy for ASN prefix-based addressing for IPv6. |
| | AI Preferences Signaling: End User Impact |
| |
|
Standards can have a major impact on end users across technological, legal, ethical, and governance dimensions, largely centering around access to information, control over their digital contributions, and data privacy. The purpose of this Internet Draft is to document the potential impact of signaling AI preferences on end users other than publishers, and to suggest some principles for the ai-pref working group to consider when assessing proposed vocabulary and definitions IETF wishes to standardize for signaling. |
| |
|
| |
| | 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. |
| |
|
| |
| | Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network. |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-12.txt |
| | Date: |
23/11/2025 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | SCRAM with Modular Crypt Format (SCRAM-MCF) |
| |
|
This document specifies SCRAM-MCF, an extension to the Salted Challenge Response Authentication Mechanism (SCRAM) family of SASL mechanisms ([RFC5802]) and HTTP Digest extensions ([RFC7616], [RFC7677]). The extension replaces the PBKDF2-specific iteration count attributes i= and s= in the server-first-message with a generic Modular Crypt Format (MCF) descriptor f=. This allows servers to use modern memory- hard key derivation functions such as Argon2, SCrypt, or bcrypt while preserving the full security properties and message flow of SCRAM. The change is fully backward compatible: servers can continue sending i= and s= for legacy clients and only send f= (or both) when the client advertises support. This document is intended to be discussed and potentially adopted by the KITTEN working group. Feedback from the KITTEN WG is welcome on the kitten@ietf.org mailing list. |
| | NTP DNS Resource Record |
| |
|
This document defines a new NTP DNS Resource Record, similar in concept to the HTTPS DNS Resource Record specified in [RFC9460]. This record enables an NTP server to indicate, via DNS, the versions of the NTP protocol it supports prior to the initiation of any NTP message exchange. |
| | Enhanced BGP Resilience |
| |
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. RFC7606 revises the error handling procedures for a number of existing attributes. The use of the "treat-as-withdraw" and "attribute discard" approaches significantly reduces the likelihood of BGP sessions being reset when receiving malformed BGP update messages, thereby greatly enhancing network stability. However, in practical applications, there are still numerous instances where BGP session oscillations occur due to the receipt of malformed BGP update messages, unrecognized attribute fields, or routing rules generated by a certain BGP AFI/SAFI that affect the forwarding of BGP messages. This document introduces some approaches to enhance the stability of BGP sessions. |
| | STI Certificate Transparency |
| |
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR eco-system, focusing on verifiable control over telephone number or service provider code resources. |
| |
|
| |
| | Constrained Resource Identifiers |
| |
| | draft-ietf-core-href-30.txt |
| | Date: |
21/11/2025 |
| | Authors: |
Carsten Bormann, Henk Birkholz |
| | Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. |
| | ICANN Registry Interfaces |
| |
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| | ICANN Registrar Interfaces |
| |
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| | Dynamic No-Entry Zone Dissemination in IPv6 Vehicular Networks |
| |
|
This document defines the Dynamic No-Entry Zone (DNEZ) information element and its dissemination mechanism using IPv6-based vehicular networks. A DNEZ is a temporary lane-level polygonal area generated by a stopped or faulty vehicle to indicate a region that surrounding vehicles may need to avoid. The primary use case is to provide redundancy when roadside perception systems fail due to occlusion, weather, or infrastructure limitations. The DNEZ is disseminated using geographically-scoped IPv6 multicast (GeoBroadcast) as defined in RFC 9366. Receiving vehicles or Road Side Units (RSUs) may rebroadcast the message to extend coverage. Local interpretation and usage of the DNEZ is implementation-specific and outside the scope of this document. |
| |
|
| |
| | 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. |
| |
|
| |
| | JSContact Version 2.0: A JSON Representation of Contact Data |
| |
|
This document defines version "2.0" of JSContact. It defines the uid property of a Card object to be optional, rather than mandatory as defined in previous version "1.0". All other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional uid property from and to vCard. It also registers the vCard JSCOMPS parameter at IANA, which was defined but not registered in RFC 9555. |
| | A Mechanism for X.509 Certificate Discovery |
| |
| | draft-ietf-lamps-certdiscovery-02.txt |
| | Date: |
19/11/2025 |
| | Authors: |
Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether to fetch the Secondary Certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of Primary Certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for seamlessly interconnecting geographically separated SD-WAN segments via a Cloud Backbone without requiring Cloud Gateways (GWs) to decrypt and re-encrypt traffic. By encapsulating IPsec- encrypted payloads within GENEVE headers (RFC 8926), the approach enables Cloud GWs to forward encrypted traffic directly between distant Customer Premises Equipment (CPEs). This reduces processing overhead, improves scalability, and preserves the confidentiality of enterprise data while ensuring secure and efficient multi-segment SD-WAN. connectivity. |
| |
|
| |
| | The HTTP QUERY Method |
| |
|
This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests but can be automatically repeated or restarted without concern for partial state changes. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. |
| | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
|
RFC 6514 describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. This document updates and obsoletes RFC 6514. The original authors of RFC 6514 are listed at the end of this document. |
| | Outer-Inner TLS (OI-TLS) |
| |
|
Outer-Inner TLS (OI-TLS) hides TLS ClientHello metadata (SNI, ALPN, cipher list, JA3) from on-path DPI by splitting a TLS session into two layers. The client first establishes an outer TLS 1.3 tunnel to an entry node with no SNI, then tunnels an ordinary TLS handshake for the backend inside that encrypted channel. This document describes the architecture, signaling, deployment considerations, and security trade-offs, together with laboratory evidence demonstrating the technique. |
| |
|
| |
| | Tracing process in IPv6 VPN Tunneling Networks |
| |
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. |
| | Use of SLH-DSA in TLS 1.3 |
| |
| | draft-reddy-tls-slhdsa-02.txt |
| | Date: |
17/11/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. |
| | OAuth Authorization Management URI |
| |
|
This specification defines a authorization_management_uri property for the OAuth Authorization Server Metadata ([RFC8414]), which allows an authorization server to specify a URI through which the user may manage the authorized clients that have access to their account. |
| | Media over QUIC Relay Benchmark Methodology |
| |
|
This document defines a comprehensive methodology for benchmarking Media over QUIC Transport (MOQT) relays to evaluate their performance under realistic conditions. The methodology utilizes configurable test profiles that simulate common media streaming scenarios including audio-only distribution, combined audio-video streaming, and multi-participant conferencing environments. The framework defines standardized message formats, synchronization mechanisms, and comprehensive metrics collection to ensure reproducible and comparable results across different relay implementations. Test scenarios cover both (QUIC) datagram and stream forwarding modes, enabling evaluation of relay performance characteristics such as throughput, latency variance, object loss rates, and resource utilization. The resulting benchmark data facilitates objective comparison and analysis of (MOQT) relay implementations, supporting informed deployment decisions and performance optimization efforts. |
| |
|
| |
| | Distribution of Service Metadata in BGP FlowSpec |
| |
|
In edge computing and distributed cloud environments, a service may be deployed on multiple instances across one or more sites, referred to as edge service. The edge service is typically associated with an ANYCAST IP address. With the emergence of Computing-Aware Traffic Steering (CATS) requirements, there is a growing need to consider both network and computing metrics when making traffic steering decisions. Traditional routing protocols lack the capability to convey compute-related information, necessitating extensions to existing protocols. This draft defines a mechanism to distribute service routes along with computing-related metadata using BGP FlowSpec. The service metadata, including compute resource status and performance metrics, can be collected by a central controller, processed, and then distributed to ingress routers using BGP FlowSpec extensions. This enables ingress routers to make path selections based not only on routing cost but also on the running environment and resource availability of edge services, thereby optimizing Quality of Experience (QoE). |
| | Hybrid Post-quantum Key Exchange SM2-MLKEM for TLSv1.3 |
| |
|
This document specifies how to form a hybrid key exchange with CurveSM2 and MLKEM in Transport Layer Security (TLS) protocol version 1.3. Related IETF drafts include [hybrid] and [ecdhe-mlkem]. |
| | Considerations for Happy Eyeballs Error Reporting |
| |
|
This document introduces diferent aspects to be considered for the Happy Eyeballs error reporting. |
| | Reclassifying SIIT-DC-DTM (RFC7756) to Standards Track |
| |
|
This document reclassifies Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode ([RFC7756]) to Standards Track. |
| | Reclassifying SIIT-DC (RFC7755) to Standards Track |
| |
|
This document reclassifies Stateless IP/ICMP Translation for IPv6 Data Center Environments ([RFC7755]) to Standards Track. |
| |
|
| |
| | Dynamic Attestation for AI Agent Communication |
| |
|
This document describes a use case for conveying remote attestation information in association with Transport Layer Security (TLS) sessions in the context of AI agent communication. It focuses on long-lived secure channel sessions where an AI agent runtime posture, covering the platform Trusted Computing Base (TCB), agent manifest (models, tools and policies) and committed runtime context, can change frequently and unpredictably. The document highlights requirements for dynamic attestation so that relying parties can base authorization decisions on the current runtime posture of the communicating agent. |
| | DKIM2 Recipient and Next Domain Signing |
| |
|
This document proposes using the DKIM2 ESMTP extension to pass a signature for each intended recipient through the SMTP session rather than splitting email at the time of signing. This approach meets the DKIM2 objective of preventing email replay, while also preserving existing SMTP delivery logic, maintaining compatibility with DKIM and avoiding multiple calls to the DKIM2 filter. Also proposed is a method of signing the next domain in the DKIM2 chain of custody independently from the DKIM2-Signature. As per RFC5321, "... each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs". The requirements outlined herein ensure the majority of DKIM2 logic can be implemented within filters or supporting code, with only minimal and isolated changes in SMTP code. |
| | QUIC Idle Timeout Update |
| |
|
QUIC supports an idle timeout for connections, which can be negotiated once during the connection handshake. This document defines QUIC extension frames that permit either endpoint to initiate an update to the idle timeout value. |
| | Fragment Header for PREOF |
| |
|
This document re-use IPv6 Fragment Header to support DetNet Packet Replication, Elimination, and Ordering Functions (PREOF). |
| | Tracing process in IPv6 VPN Tunneling Networks |
| |
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. |