| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (which is called NRP Selector) need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. |
| | IPv6 Node Requirements |
| |
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. |
| | YANG Data Model for IPv6 Neighbor Discovery |
| |
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. |
| | Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| | draft-ietf-ace-edhoc-oscore-profile-09.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. |
| | Protecting EST Payloads with OSCORE |
| |
| | draft-ietf-ace-coap-est-oscore-09.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. |
| | Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. |
| | CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. |
| | BRSKI discovery and variations |
| |
|
This document specifies how to make BRSKI communications autoconfiguring, extensible and resilient in the face of simultaneous use of different variations of the BRSKI protocol (BRSKI, BRSKI-AE, BRSKI-PRM, constrained BRSKI, stateless constrained BRSKI proxies). This document specifies a data model, IANA registry and BRSKI component procedures to achieve this. This document does not define any new discovery methods. Instead, its data model allows to signal all current (and future) variations of the BRSKI family of protocols consistently via different existing network discovery mechanisms: DNS-SD, CoAP discovery (CORE-LF) and GRASP. Additional/future discovery mechanisms can also be supported through the IANA registry. Automatic resiliency and load-sharing are enabled through the use of discovery mechanisms and the provisioning of multiple instances of BRSKI components such as registrars and Join Proxies. This document specifies the procedures to support load-sharing and (fast) failover under failure and recovery of redundant components. Future proof deployments of BRSKI requires Join Proxies that automatically support any current and future BRSKI variation. This document specifies the procedures how Join Proxies can support this through specific Join Proxy protocol behavior and the use of discovery mechanisms. The specification for discovery of pledges by their IDevID as introduced by BRSKI-PRM is refined in this document. |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. |
| | EVPN multi-homing support for L3 services |
| |
|
This document describes the use of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to improve network availability and load balancing for Layer 3 (L3) services with EVPN. In this approach, all synchronized routes ensure the correct L3 state within Virtual Routing and Forwarding (VRF) instances. Unlike traditional deployments, these L3 services operate entirely at Layer 3 and do not require Layer 2 constructs such as Ethernet Virtual Instances (EVIs), MAC-VRFs, Bridge Domains (BDs), or Integrated Routing and Bridging (IRB) interfaces. |
| | EVPN-VPWS Seamless Integration with L2VPN VPWS |
| |
|
This document presents a solution for migrating L2VPN Virtual Private Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) services. The solution allows the coexistence of EVPN and L2VPN services under the same point-to-point VPN instance. By using this seamless integration solution, a service provider can introduce EVPN into their existing L2VPN network or migrate from an existing L2VPN based network to EVPN. The migration may be done per pseudowire or per flexible-crossconnect (FXC) service basis. This document specifies control-plane and forwarding behaviors. |
| | IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI |
| |
| | draft-ietf-bess-v4-v6-pe-all-safi-03.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Gyan Mishra, Sudha Madhavi, Adam Simpson, Mankamana Mishra, Jeff Tantsura, Shuanglong Chen |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the four major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. |
| | Considerations for Benchmarking Network Performance in Containerized Infrastructures |
| |
|
Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. |
| | Benchmarking Methodology for Segment Routing |
| |
| | draft-ietf-bmwg-sr-bench-meth-05.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). It builds upon RFC 2544, RFC 5180, RFC 5695 and RFC 8402. |
| | CATS Metrics Definition |
| |
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from the computing domain used for CATS. |
| | A YANG data model to manage configurable DWDM optical interfaces |
| |
| | draft-ietf-ccamp-dwdm-if-param-yang-14.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This memo defines a YANG model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The YANG model defined in this memo can be used for Optical Parameters monitoring and/or configuration of DWDM interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. |
| | A YANG Data Model for WDM Tunnels |
| |
| | draft-ietf-ccamp-wdm-tunnel-yang-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | BBR Congestion Control |
| |
| | draft-ietf-ccwg-bbr-04.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Neal Cardwell, Ian Swett, Joseph Beshay |
| | Working Group: |
Congestion Control Working Group (ccwg) |
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. |
| | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
| |
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate, and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. |
| | Interactive Sigma Proofs |
| |
|
A Sigma Protocol is an interactive zero-knowledge proof of knowledge that allows a prover to convince a verifier of the validity of a statement. It satisfies the properties of completeness, soundness, and zero-knowledge, as described in Section 3. This document describes Sigma Protocols for proving knowledge of pre- images of linear maps in prime-order elliptic curve groups. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. |
| | Fiat-Shamir Transformation |
| |
|
This document describes how to construct a non-interactive proof via the Fiat–Shamir transformation, using a generic procedure that compiles an interactive proof into a non-interactive one by relying on a stateful hash object that provides a duplex sponge interface. The duplex sponge interface requires two methods: absorb and squeeze, which respectively read and write elements of a specified base type. The absorb operation incrementally updates the sponge's internal hash state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with various hash functions based on permutation or compression functions. This specification also defines codecs to securely map elements from the prover into the duplex sponge domain, and from the duplex sponge domain into verifier messages. |
| | Observe Notifications as CoAP Multicast Responses |
| |
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. |
| | Key Update for OSCORE (KUDOS) |
| |
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. |
| | Constrained Application Protocol (CoAP) Performance Measurement Option |
| |
| | draft-ietf-core-coap-pm-05.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fabio Bulgarella, Yongqing Zhu |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. |
| | Identifier Update for OSCORE |
| |
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. |
| | URI-Path abbreviation in CoAP |
| |
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus registering (relatively verbose) well-known URI paths. This document introduces an option that allows expressing well-known paths in as little as two bytes. |
| | Using Proxies for Observe Notifications as CoAP Multicast Responses |
| |
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. The present version -00 refers to version -12 of draft-ietf-core- observe-multicast-notifications, which includes content about proxies that is also included in the present document. Such content will be removed from draft-ietf-core-observe-multicast-notifications in its next revision. |
| | Mobile User Plane Architecture for Distributed Mobility Management |
| |
| | draft-ietf-dmm-mup-architecture-01.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Satoru Matsushima, Katsuhiro Horiba, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Jakub Horn |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case (SRv6 MUP) due to the DMM requirement, and is suitable for mobile services which require a large IP address space. |
| | Operational Recommendations for DS Automation |
| |
|
Enabling support for automatic acceptance of DS parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parent operator, often a registry or registrar, to make a number of technical decisions. This document describes recommendations for new deployments of such DS automation. |
| | Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option |
| |
| | draft-ietf-dnssd-tsr-01.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Ted Lemon, Esko Dijk |
| | Working Group: |
Extensions for Scalable DNS Service Discovery (dnssd) |
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD advertising proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. |
| | The DRIP DET public Key Infrastructure |
| |
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. |
| | BMP YANG Module |
| |
| | draft-ietf-grow-bmp-yang-07.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, Narasimha Prasad |
| | Working Group: |
Global Routing Operations (grow) |
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). |
| | Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
| |
| | draft-ietf-happy-happyeyeballs-v3-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Tommy Pauly, David Schinazi, Nidhi Jaju, Kenichi Ishibashi |
| | Working Group: |
Heuristics and Algorithms to Prioritize Protocol deploYment (happy) |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| | Resumable Uploads for HTTP |
| |
|
HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was received prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| | IAB Processes for Management of IETF Liaison Relationships |
| |
| | draft-iab-rfc4052bis-01.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Suresh Krishnan, Mirja Kuehlewind, Qin WU |
| | Working Group: |
Internet Architecture Board (iab) |
|
This document discusses the procedures used by the IAB to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers, and the expectations of the IAB in establishing liaison relationships. |
| | Pacing in Transport Protocols |
| |
| | draft-irtf-iccrg-pacing-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Internet Congestion Control (iccrg) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | BGP Link-State Extensions for BGP-only Networks |
| |
| | draft-ietf-idr-bgp-ls-bgp-only-fabric-04.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Ketan Talaulikar, Aravind MahendraBabu, Clarence Filsfils, Krishnaswamy Ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address- family and the procedures for advertisement of topology information in a BGP-only network. |
| | BGP Next-next Hop Nodes |
| |
|
BGP speakers learn their next hop addresses for NLRI in RFC 4271 in the NEXT_HOP field and in RFC 4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. |
| | Responsiveness under Working Conditions |
| |
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. |
| | A YANG Network Data Model for Inventory Topology Mapping |
| |
|
This document defines a YANG data model to map the network inventory data with the topology data to form a base underlay network. The data model facilitates the correlation between the layer (e.g., Layer 2 or Layer 3) topology information and the inventory data of the underlay network for better service provisioning, network maintenance operations, and other assessment scenarios. |
| | A YANG Network Data Model of Network Inventory Software Extensions |
| |
|
This document extends the base Network Inventory YANG model to support non-physical network elements (NEs), such as controllers, virtual routers, and virtual firewalls, as well as software components like platform operating systems and software modules. In addition to the software revisions and patches already defined in the base model, this extension introduces software status and time stamp information. |
| | A YANG Module for Entitlement Inventory |
| |
|
This document proposes a YANG module for incorporating entitlements in a network inventory, encompassing both virtual and physical network elements. Entitlements define the rights for their holder to use specific capabilities in a network element(s). The model is rooted by the concept of the capabilities offered by an element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. |
| | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) |
| |
| | draft-ietf-lake-authz-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| | Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, In order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. |
| | EDHOC Authenticated with Pre-Shared Keys (PSK) |
| |
| | draft-ietf-lake-edhoc-psk-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Elsa, Goeran Selander, John Mattsson, Rafael Marin-Lopez, Francisco Lopez |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. |
| | Remote attestation over EDHOC |
| |
| | draft-ietf-lake-ra-03.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Yuxuan Song, Goeran Selander |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. |
| | Certificate Management over CMS (CMC) |
| |
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFC 5273 and RFC 6402. |
| | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFC 5274 and RFC 6402. |
| | LISP L2/L3 EID Mobility Using a Unified Control Plane |
| |
| | draft-ietf-lisp-eid-mobility-17.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. |
| | YANG Data Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | IGP Flex Soft Dataplane |
| |
|
Advertisement of IGP Flex-Algo participation requires a dataplane context. This document defines a "soft dataplane" usable in cases where existing defined dataplanes are not suitable. |
| | Personal Data Portability Archive |
| |
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. |
| | Automatic Configuration of Email,Calendar,and Contact Server Settings |
| |
|
This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures. |
| | DLEP Radio Quality Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. |
| | DLEP Radio Band Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide information about frequency bands used by the radio. |
| | DLEP Radio Channel Utilization Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. |
| | Non-source-routed Multicast in SR Networks |
| |
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. |
| | An Architecture for More Instant Messaging Interoperability (MIMI) |
| |
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-05.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| | Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| | Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol |
| |
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. |
| | Scalable Quality Extension for the Opus Codec (Opus HD) |
| |
|
This document updates RFC6716 to add support for a scalable quality layer. |
| | MLS Virtual Clients |
| |
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. |
| | Network Overlay Impacts to Streaming Video |
| |
|
This document examines the operational impacts on streaming video applications resulting from network policy changes introduced by network overlays. Such overlays may alter IP address assignment, transport protocols, routing behavior, or DNS resolution. These changes can, in turn, affect critical aspects of content delivery, including latency, CDN cache selection, delivery path optimization, traffic classification, and content access controls. |
| | Media over QUIC Transport |
| |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Privacy Pass Authentication for Media over QUIC (MoQ) |
| |
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | RESTCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the changed data was observed. |
| | YANG Schema Comparison |
| |
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm. |
| | YANG module file name convention |
| |
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and draft-ietf-netmod- rfc8407bis. |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | Extensible YANG Model for Network Telemetry Messages |
| |
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. |
| | Considerations of network/system for AI services |
| |
| | draft-irtf-nmrg-ai-deploy-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Pedro Martinez-Julia, Qin WU |
| | Working Group: |
Network Management (nmrg) |
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, it has changed from running only on very high-performance servers to running on commodity servers, with affordable, small-scale hardware, including microcontrollers, low-performance CPUs, and AI chipsets. This document outlines how to configure the network and system for an AI inference service, providing AI services in a distributed manner. It also outlines the factors to consider when a client connects to a cloud server and an edge device to requests an AI service. It describes some use cases for deploying network-based AI services, such as self-driving vehicles and network digital twins. |
| | CoAP: Non-traditional response forms |
| |
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. The design spaces for the new CoAP Options proposed to represent these responses are now sufficiently understood that they can be developed to standards-track specifications, either in this document or by transferring the specification for an Option to a document that that Option closely works with. |
| | Storing BMP messages in MRT Format |
| |
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages. |
| | CoAP over GATT (Bluetooth Low Energy Generic Attributes) |
| |
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. |
| | PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE |
| |
|
This draft specify extensions to PCEP protocol when a PCE-based controller is responsible for allocates the BIER-TE information(BIER subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc), then PCC generate a "Bit Index Forwarding Table"(BIFT). |
| | DC aware TE topology model |
| |
|
This document proposes the extension of the TE topology model for including information related to data center resource capabilities. For that purpose, it defines a YANG module to augment TE topologies with awareness of data-center computing resources. Although the model is designed to be compatible with TE aware topologies, it can also be applied to non-TE networks. |
| | Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation |
| |
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. // The present version of this document is mostly a proof of concept; // it received positive initial feedback on the approach taken and is // awaiting completion of the initial implementation. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension |
| |
|
This document defines the IKEv2 Link Maximum Atomic Packet and Packet Too Big Extension to limit reassembly operations being performed by the egress security gateway. This extension enables an egress security gateway to notify its ingress counterpart that fragmentation is happening or that the received (and potentially reassembled) ESP packet is too big and thus cannot be decrypted. In both cases, the egress node provides Maximum Transmission Unit (MTU) information. Such information enables the ingress node to configure appropriately its Tunnel Maximum Transmission Unit - also designated as MTU or Tunnel MTU (TMTU) - to prevent fragmentation or too big packets to be transmitted. |
| | Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) |
| |
|
As operators migrate from an IPv4 core to an IPv6 core for global table routing over the internet, the need arises to be able provide routing connectivity for customers IPv4 only networks. This document provides a solution called 4Provider Edge, "4PE" that connects IPv4 islands over an IPv6-Only network. |
| | More Instant Messaging Interoperability (MIMI) Identity Concepts |
| |
|
This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-15.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | EVPN Multicast Forwarding for EVPN to EVPN Gateways |
| |
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. |
| | Identity for E2E-Secure Communications |
| |
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. |
| | Source IPv6 Address Programmability |
| |
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information |
| | EVPN Inter-Domain Option-B Solution |
| |
|
An EVPN Inter-Domain interconnect solution is required when two or more sites of the same Ethernet Virtual Private Network (EVPN) are connected to different IGP domains or Autonomous Systems (AS) and need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for this type of EVPN connectivity. While several documents address specific aspects of this interconnect approach, none provide a comprehensive overview of how Inter-Domain Option-B connectivity affects EVPN procedures. This document examines the behavior of EVPN procedures in an Inter-Domain Option-B network and proposes solutions to the identified issues. |
| | Realization of Composite IETF Network Slices |
| |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. |
| | Aircraft to Anything AdHoc Broadcasts and Session |
| |
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. |
| | Green Challenges in Computing-Aware Traffic Steering (CATS) |
| |
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. |
| | Multiple Algorithm Rules in DNSSEC |
| |
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035 and 6840. |
| | Validity of SR Policy Candidate Path |
| |
|
An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active (i.e., installed in forwarding and usable for steering of traffic). Each CP in turn may have one or more SID-List of which one or more may be active; when multiple SID-List are active then traffic is load balanced over them. However, a candidate path is valid when at least one SID-List is active. This candidate path validity criterion cannot meet the needs of some scenarios. This document defines the new candidate path validity criterion. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Path Computation Based on Precision Availability Metrics |
| |
| | draft-contreras-pce-pam-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Luis Contreras, Fernando Agraz, Salvatore Spadaro, Quan Xiong |
| | Working Group: |
Individual Submissions (none) |
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. |
| | Secure Shell Key Exchange Method Using Chempat Hybrid of Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512 |
| |
|
This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on Classic McEliece (mceliece6688128) and X25519 with SHA-512 using Chempat as the combiner. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-ssh-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-mceliece. |
| | CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs) |
| |
|
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. This specification extends this functionality to CBOR Web Tokens (CWTs). |
| | Definition for Aggregated BMP Route Monitoring Message |
| |
|
This document proposes an aggregated BMP route monitoring message based on the BMP Multi-peer Header Message defined in [I-D.liu-grow- bmp-multiple-peer-header]. It can compress multiple BMP route monitoring messages into one aggregated BMP route monitoring message to reduce the amount of reported BMP route monitoring messages and reduce the network overhead. |
| | Intent Translation Engine for Intent-Based Networking |
| |
| | draft-pedro-ite-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Pedro Martinez-Julia, Jaehoon Jeong, Takuya Miyasaka, Diego Lopez |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the schemas and models required to realize the data formats and interfaces for Intent-Based Networking (IBN). They are needed to enable the composition of services to build a translation engine for IBN-based network management. This intent translation engine (called an intent translator) is an essential function for network intents to be enforced into a target network for the configuration and management of the network and its security. |
| | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
| |
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. |
| | Advanced Professional Video |
| |
| | draft-lim-apv-09.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the bitstream format of Advanced Professional Video (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production. |
| | A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology |
| |
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Intermediate System to Intermediate System (IS-IS). This document augments the 'ietf-network' and 'ietf-network-topology' data models by adding IS- IS concepts and explains how the data model can be used to represent the IS-IS topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | End-to-End Secure Objects for Media over QUIC Transport |
| |
|
This document describes an end-to-end authenticated encryption scheme for application objects intended to be delivered over Media over QUIC Transport (MOQT). We reuse the SFrame scheme for authenticated encryption of media objects, while suppressing data that would be redundant between SFrame and MOQT, for an efficient on-the-wire representation. |
| | 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS |
| |
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. |
| | Common BMP Route-Monitoring Messages for Routes Unchanged by Policy |
| |
|
A route unmodified by the inbound policy on a monitored router is included both in Pre-Policy Adj-RIB-In as well as Post-Policy Adj- RIB-In Route-Monitoring messages when both the Pre-Policy and Post- Policy Route-Monitoring modes are enabled. Similarly, a route unmodified by the outbound policy is included in Pre-Policy Adj-RIB- Out as well as Post-Policy Adj-RIB-Out Route-Monitoring messages. This document defines a method to avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out. |
| | Multiple Hop Unaffiliate BFD |
| |
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. |
| | A YANG Data Model for Open Shortest Path First (OSPF) Topology |
| |
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | BGP Extensions of SR Policy for Composite Candidate Path |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. |
| | Advertising Router Information |
| |
| | draft-zzhang-rtgwg-router-info-05.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Zhaohui Zhang, Kevin Wang, Changwang Lin, Niranjan Vaidya, Jeff Tantsura, Yisong Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes. |
| | Logging over Media over QUIC Transport |
| |
|
Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. |
| | Metrics over MOQT |
| |
|
This document specifies how to send metrics type information over the Media Over QUIC Transport (MOQT). Many systems produce significant volumes of metrics which either are not all needed at the same time for consumption by collection/ aggregation endpoints or may also compete for bandwidth with the primary application, thus exacerbating congestion conditions especially in low-bandwidth networks. Delivering these over architectures enabled by publish/subscribe transport like Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport], allows metrics data to be prioritized within the congestion context of the primary application as well as enabling local nodes to cache the metric value to be later retrieved via new subscriptions. |
| | Parallel NFS (pNFS) Flexible File Layout Version 2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Layout Type Version 2 is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data protection is also added to provide integrity. Both Client-side mirroring and the Erasure Coding algorithms are used for data protection. |
| | Current State of the Art for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Networks (HP-WANs) represent a critical infrastructure for the modern global Research and Education (R&E) community, facilitating collaboration across national and international boundaries. These networks include global education and research networks, such as GÉANT, Internet2, Janet, ESnet, CANARIE, CERNET, and others, and also refer to large scale commercial dedicated networks built by hyperscalers and operators. They are designed to support the ever-growing transmission of vast amounts of data generated by scientific research, high-performance computing, distributed AI-training and large-scale simulations. This document provides an overview of the terminology and techniques used for existing HP-WANs. It also explores the technological advancements, operational tools, and future directions for HP-WANs, emphasising their role in enabling cutting-edge scientific research, AI training and massive R&E data analysis. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various Label Switched Path (LSP) identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. |
| | Secure UAS Stateless Network RID |
| |
|
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-green-api-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Marisol Amador, Jan Lindblad, Adrian Sanchez |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | MoQ Media Interop |
| |
|
This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT], using LOC[loc] packaging. |
| | SAVI in a LISP network |
| |
|
This document specifies the procedures for Source Address Validation of LISP Endpoint Identifiers (EID). The implementation of these mechanisms provides endpoint detection, on-boarding and roaming support in LISP networks, while protecting against IP address spoofing. |
| | Traceability Claims |
| |
|
This document defines claims to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. These claims are registered for use in both CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs). |
| | BMP Snapshots |
| |
|
BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The issue is that the necessary information to produce a complete view and enabling correct processing of all messages in the stream, is only sent out at the beginning of the BMP session. This document introduces the concept of BMP Snapshots, enabling BMP stations to synchronize mid-stream, and, providing the basis for self-contained, time-binned archiving of BMP data. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. |
| | Source Buffer Management |
| |
|
In the past decade there has been growing awareness about the harmful effects of bufferbloat in the network, and there has been good work on developments like L4S to address that problem. However, bufferbloat on the sender itself remains a significant additional problem, which has not received similar attention. This document offers techniques and guidance for host networking software to avoid network traffic suffering unnecessary delays caused by excessive buffering at the sender. These improvements are broadly applicable across all datagram and transport protocols (UDP, TCP, QUIC, etc.) on all operating systems. |
| | WIMSE Credential Exchange |
| |
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. |
| | Stateless Hash-Based Signatures for Secure Shell (SSH) |
| |
|
This document describes the use of Sphincs+/SLH-DSA digital signatures, standalone and as a hybrid with Ed25519/Ed448, in the Secure Shell (SSH) protocol. |
| | Privacy Pass Reverse Flow |
| |
|
This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue new tokens in response to a request in which a token is redeemed. |
| | Dynamic Overlay Load Balancing |
| |
|
This document specifies a mechanism for an overlay service ingress PE to dynamically load-balance traffic to Multi-Homing PEs based on near real-time access link information advertised by those PEs. |
| | Lightweight Authentication for Encapsulation Header |
| |
|
This document specifies a lightweight authentication mechanism (KeyID, anti-replay, algorithms, truncation, and keying) intended to be reused by multiple protocol profiles. Concrete profiles define where the authentication data is carried and the exact coverage rules for header fields. |
| | Messaging Layer Security Credentials using Selective Disclosure JSON and CBOR Web Tokens |
| |
|
The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time and low latency of High Performance Wide Area Networks (HP-WAN). It focuses on key congestion control functions to facilitate host-to-network collaboration and perform rate negotiation, such as QoS policy, admission control, and traffic scheduling. |
| | Large Model based Agents for Network Operation and Maintenance |
| |
|
Current advancements in AI technologies, particularly large models, have demonstrated immense potential in content generation, reasoning, analysis and so on, providing robust technical support for network automation and self-intelligence. However, in practical network operations, challenges such as system isolation and fragmented data lead to extensive manual, repetitive, and inefficient tasks, the improvement of intelligence level is very necessary. This document identifies typical scenarios requiring enhanced intelligence, and explains how AI Agents and large model technologies can empower networks to address operational pain points, reduce manual efforts, and explore impacts on network data, system architectures, and interfaces correspondingly. It further explores and summarizes standardization efforts in implementation. |
| | Remote Attestation with Multiple Verifiers |
| |
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. |
| | YANG Datastore Telemetry (YANG Push Lite) |
| |
|
YANG Push Lite is a YANG datastore telemetry solution, as an alternative specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. |
| | PCEP extensions for energy consumption |
| |
|
[draft-liu-spring-sr-energy-consumption-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document further details the process of using the PCEP protocol for energy consumption based path requests. The Path Computation Element Communication Protocol (PCEP) provides mechanisms that enable Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs). This document describes the extension to PCEP for conveying link energy consumption and node energy consumption, allowing path computation based on these energy consumption information. |
| | MoQ qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for MoQ. |
| | ACP free "Automation Network Infrastructure" for simple in-network automation (aNI) |
| |
|
This document describes how to to build the software infrastructure for distributed automation agents using a lightweight variation of the "Autonomic Networking Infrastructure" (ANI), by using the existing ANI domain keying material (certificates and trust anchors) as well as the protocols GRASP and BRSKI protocols, but eliminating the expensive to implement "Autonomic Control Plane" (ACP) and adding proxying "Autonomic Software Agents" (ASA) instead. The resulting infrastructure is called "automation Network Infrastructure" and can be implemented solely as application level software components on routers, switches or co-located managemenet devices, avoiding the need to change any router or switches forwarding or control-plane protocols. The aNI achieves mosts of the benefits of the ANI but foregoes the ability to easily make pre-existing, insecure control-plane protocols secure or provide all the same protection against operator or SDN controller misconfigurations that the ACP provides. |
| | Secure Asset Transfer Protocol (SATP) Implementation Guide |
| |
|
This memo provides implementation guidelines for the Secure Asset Transfer Protocol (SATP). It is intended for developers of SATP gateway and digital asset networks they represent. This document also clarifies the core SATP processing workflow and offers recommendations to ensure interoperable implementations, particularly in environments where multiple gateways may represent the same network. |
| | Proposal for Updates to Guidance on Packet Reordering |
| |
|
Several link technology standards mandate that equipment guarantee in-order delivery of layer 2 frames, apparently due to a belief that this is required by higher layer protocols. To meet this requirement they implement a "resequencing" operation to restore the original packet order. This can introduce delays that result in net degradation of performance. Modern TCP and QUIC implementations support features that significantly improve their tolerance to out- of-order delivery. This draft is intended to provide new information for layer 2 technology standards regarding the need to assure in- order delivery to support IETF protocols. |
| | CCNx Content Versioning |
| |
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content sharing the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. |
| | Distributed MLS |
| |
|
The Messaging Layer Security (MLS) protocol enables a group of participants to negotiate a common cryptographic state for messaging, providing Forward Secrecy (FS) and Post-Compromise Security (PCS). There are some use cases where message ordering challenges may make it difficult for a group of participants to agree on a common state or use cases where reaching eventual consistency is impractical for the application. This document describes Distributed-MLS (DMLS), a composition protocol for using MLS sessions to protect messages among participants without negotiating a common group state. |
| | Methods for Mitigation of Congestion and Load Issues on RADIUS Servers |
| |
|
The RADIUS protocol as defined in [RFC2865] does not have a means to signal server overload or congesition to the clients. This can lead to load problems, especially in a federated RADIUS proxy fabric. This document attempts to fix this. |
| | Decentralized Messaging Layer Security |
| |
|
Messaging Layer Security (MLS) provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). To facilitate agreement between group members, MLS requires a Delivery Service (DS) component that orders of the handshake messages (Commits) that allow changes to the group state. In decentralized settings without a central authoritative entity to enforce ordering, group members will likely have to retain key material so they can process Commits out-of-order. Retaining key material, however, significantly reduces the FS of the protocol. This draft specifies Decentralized MLS (DMLS), based on the Fork-Resilient Continuous Group Key Agreement protocol FREEK proposed by Alwen et al. [FRCGKA]. In essence, DMLS extends MLS such that key material can be retained to process Commits out-of- order with recuded impact to FS, thus allowing safer deployment in decentralized environments. |
| | HTTP Message Signatures Directory |
| |
|
This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as new HTTP Method Context to allow for in-band key discovery. |
| | HTTP Message Signatures for automated traffic Architecture |
| |
|
This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Benoit Claise, Luis Contreras, Jan Lindblad, Marisol Amador, Emile Stephan, Qin WU |
| | Working Group: |
Individual Submissions (none) |
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. |
| | Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0 |
| |
|
The Automatic Certificate Management Environment (ACME) protocol allows server operators to obtain TLS certificates for their websites, based on a demonstration of control over the website's domain via a fully-automated challenge/response protocol. OpenID Federation 1.0 defines how to build a trust infrastructure using a trusted third-party model. It uses a trust evaluation mechanism to attest to the possession of private keys, protocol specific metadata and miscellaneous administrative and technical information related to a specific entity. This document defines how X.509 certificates associated with a given OpenID Federation Entity can be issued by an X.509 Certification Authority through the ACME protocol to the organizations which are part of a federation built on top of OpenID Federation 1.0. |
| | Authoritative DNS Transport Signaling |
| |
|
This document proposes a mechanism for authoritative DNS servers to signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)). This signaling may either be provided within the Additional section of authoritative DNS responses or be the result of direct DNS queries. The former, "opportunistic mode" is hint-based and aims to enable resolvers to discover alternative transports efficiently and then opportunistically upgrade connections to the authoritative, thereby improving privacy, security, and performance for subsequent interactions. The mechanism is designed to not require any protocol change or additional queries. It is safe, backward-compatible, and effective even when DNSSEC validation of the hint is not possible or desired. In certain circumstances and with additional overhead it is also possible to use direct queries to securely obtain authentication information for the authoritative that can then be used to authenticate an encrypted connection. It is also possible to establish a "validated mode" where the communication between the resolver and the authoritative server is provably both secure and authentic. Validated mode may not always be possible, depending on whether the resolver is able to DNSSEC validate the signal or not. When Validated mode is possible it does provide a stronger and more trustworthy connection. This document proposes an improvement to the opportunistic (but blind) testing of alternative transports suggested in RFC9539 by providing a mechanism by which a responding authoritative server may signal what alternative transports it supports. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-transport-signaling (https://github.com/johanix/draft-johani-dnsop-transport-signaling). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Multipath Traffic Engineering for Segment Routing |
| |
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. |
| | Further considerations on AI Agent Authentication and Authorization Based on OAuth Extension |
| |
|
Agent Communication Network(ACN) is becoming a promising and fundamental infrastructure for most vertical industries. To construct and build a scalable and trustable ACN, authentication and authorization of AI agents are critical requirements. This document extends the model of OAuth and proposes new workflows for AI agent authentication and authorization. |
| | Network Digital Twin based Architecture for AI driven Network Operations |
| |
| | draft-wmz-nmrg-agent-ndt-arch-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Qin WU, Cheng Zhou, Luis Contreras, Sai Han, Lionel Tailhardat, Yong-Geun Hong |
| | Working Group: |
Individual Submissions (none) |
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Integrating a Network Digital Twin into network management together with AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Network Digital Twin and AI which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together. It provides a cookbook of existing technologies to satisfy the architecture and realize intent-based networking to meet the needs of the network service. |
| | Post-Quantum Algorithms guidance |
| |
|
This document provides general information (such as parameter sizes, security assumptions, and targeted security models) on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. The cryptographic schemes described in this document are among those recommended by major security agencies and/or standardization bodies, and are believed to be secure against Cryptographically Relevant Quantum Computer (CRQC). The goal of this document is to offer a high-level overview of these schemes and their distinguishing features, to help implementers, protocol designers, standards developers, and policymakers in understanding and selecting appropriate post-quantum cryptographic primitives for use in protocols and systems. By aggregating and presenting this information in a unified format, this document aims to facilitate informed decision-making and interoperability during the migration to post-quantum cryptography, and to encourage consistent practices when evaluating and deploying Post-Quantum Cryptography (PQC) schemes in cryptographic protocols. |
| | RTP Payload Format for Avatar Representation Format (ARF) Animations |
| |
|
This memo outlines RTP payload formats for the animation stream format as defined in the ISO/IEC 23090-39 specification (MPEG-I Avatar Representation Format). An animation stream format is composed of Avatar Animation Units (AAU) including an AAU header and zero or more AAU packets. The RTP payload header format allows for packetization of an AAU unit in an RTP packet payload as well as fragmentation of an AAU into multiple RTP packets. |
| | Usecase and requirement of deploying PFC and fine-grained flow control |
| |
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. |
| | Leaf Operation Intents |
| |
|
The Messaging Layer Security (MLS) protocol defined in [RFC9420] is an asynchronous secure group messaging protocol, which allows group members to propose their removal from a group. However, in some cases MLS clients can't reliably use regular Remove or SelfRemove proposals to leave a group because they don't have an up-to-date group state. This document specifies a LeafOperationIntent, which does not need an up-to-date group state but which retains sufficient binding to the client's current state to avoid replay attacks. |
| | FANTEL Use Cases and Requirements in Wide Area Network |
| |
|
This document introduces the main scenarios related to AI services in WAN, as well as their requirements for FANTEL (FAst Notification for Traffic Engineering and Load balancing) in these scenarios. Traditional network management mechanisms are often constrained by slow feedback and high overhead, limiting their ability to react quickly to sudden link failures, congestion, or load imbalances. Therefore, these AI services need FANTEL to provide real-time and proactive notifications for traffic engineering and load balancing, meeting the requirements of ultra-high throughput and lossless data transmission. |
| | Domain Name Specification for DKIM2 |
| |
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. |
| | Multicast usage in LLM MoE |
| |
|
Large Language Models (LLMs) have been widely used in recent years. The Mixture of Experts (MoE) architecture is one of the features of LLMs that enables efficient inference and cost-effective training. With the MoE architecture, there are potential multicast use cases such as tokens dispatching. This draft attempts to analyze these use cases. |
| | Stateless Encryption Scheme of Enhanced Encapsulating Security Payload (EESP) |
| |
|
This draft first introduces several use cases for stateless encryption, analyzes and compares some existing stateless encryption schemes in the industry, and then attempts to propose a general and flexible stateless encryption scheme based on the summarized requirements. |
| | Quantum-Resistant Cipher Suites for EDHOC |
| |
|
The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. |
| | An Intent Translation Framework for Internet of Things |
| |
|
The evolution of 6G networks and the expansion of Internet of Things (IoT) environments introduce new challenges in managing diverse networked resources. Intent-based management frameworks enable operators to express desired network outcomes using high-level intents, often articulated in natural language. However, converting these expressions into machine-executable policy configurations remains an open challenge. This document defines an intent translation framework designed to bridge the gap between user-issued intents and structured policy representations for 6G enabled IoT systems. The framework accepts natural language intent as input and produces a policy document in a structured format, such as YAML, that aligns with the intent model defined in 3GPP in [TS-28.312]. The framework consists of modular components responsible for processing input, aligning user intent with domain knowledge, evaluating semantic confidence, and generating standardized output. This modularity supports transparency, interoperability, and automated policy enforcement in next-generation network infrastructures. |
| | Integration of Remote Attestation with Key Negotiation and Key Distribution mechanisms |
| |
|
This draft proposes a lightweight security enhancement scheme based on integration of remote attestation with key negotiation and key distribution. Correctly integrating the main steps of end-to-end key negotiation into the remote attestation process may provide more security and flexibility. |
| | DNS data representation for use in RESTful Provisioning Protocol (RPP) |
| |
|
This document proposes a unified, extensible JSON representation for DNS resource records for use in the RESTful Provisioning Protocol (RPP). The aim is to create a single, consistent structure for provisioning all DNS-related data - including delegation, DNSSEC, and other record types - that directly mirrors the DNS data model and being mappable to existing EPP model of requests and responses same time. This approach simplifies the adoption of both current and future DNS features by aligning the provisioning format with the target system, thereby streamlining the management of domain names and related objects within RPP. |
| | Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option |
| |
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. |
| | A YANG Data Model for SIMAP |
| |
| | draft-havel-nmop-simap-yang-01.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Olga Havel, Nigel Davis, Benoit Claise, Oscar de Dios, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for Service & Infrastructure Maps (SIMAP). It extends the RFC8345 YANG modules to support all SIMAP requirements. This document will only focus on modelling proposal for each of the requirements not supported by RFC8345. Any related terminology, concepts, use cases and requirements are defined outside of this draft and this draft will only refer to them, analyze how to model and propose the implementation solutions. |
| | CNI Telco-Cloud Benchmarking Considerations |
| |
|
This document investigates benchmarking methodologies for Kubernetes Container Network Interfaces (CNIs) in Edge-to-Cloud environments. It defines performance, scalability, and observability metrics relevant to CNIs, and aligns with the goals of the IETF Benchmarking Methodology Working Group (BMWG). The document surveys current practices, introduces a repeatable benchmarking frameworks (e.g., CODEF), and proposes a path toward standardized, vendor-neutral benchmarking procedures for evaluating CNIs in microservice-oriented, distributed infrastructures. |
| | Reclassifying EAM (RFC7757) to Internet Standard |
| |
|
This document reclassifies Explicit Address Mappings for Stateless IP/ICMP Translation ([RFC7757]) to Internet Standard. |
| | ECN and DSCP support for HTTPS's Connect-UDP |
| |
|
HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. QUIC and Real-time transport protocol (RTP) are examples of transport protocols that use UDP and support Explicit Congestion Notification (ECN) and provide the necessary feedback. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP. |
| | AI Agent protocols for 6G systems |
| |
| | draft-stephan-ai-agent-6g-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Emile Stephan, Roland Schott, Diego Lopez, Xiaodong Duan, Lionel Morand |
| | Working Group: |
Individual Submissions (none) |
|
Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols. |
| | Consideration for IP-Based Satellite Routing Protocol |
| |
|
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations. |
| | RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels |
| |
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. |
| | P2P Chat with MoQ |
| |
|
This protocol is designed for small groups of users sending relatively small messages. It is optimized for the assumption that a node will come online and collect all messages at least once every 15 days and that some nodes that act as mirrors will be online most of the time but may come and go over long periods of time. |
| | A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions |
| |
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. |
| | Mapping Open Cybersecurity Schema Framework Events to Media over QUIC Transport |
| |
|
This document defines a mapping specification for representing Open Cybersecurity Schema Framework (OCSF) events, categories, and profiles using Media over QUIC Transport (MOQT) tracks. The mapping leverages MOQT's hierarchical data model and publish/subscribe architecture to enable real-time, in-network cached, scalable distribution of cybersecurity event data across networks while maintaining OCSF's structured taxonomy and semantic relationships. |
| | Applicability & Manageability consideration for SCONE |
| |
|
This document describes the applicability and manageability considerations for providing throughput guidance to application endpoints in telecommunications service provider networks supporting the Standard Communication with Network Elements (SCONE) protocol. |
| | Network infrastructure Hiding Protocol |
| |
|
The Network infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to implement Zero Trust principles by rendering protected network resources invisible to unauthorized entities. By requiring authentication before connection and operating at OSI layers 5 , NHP conceals IP addresses, ports, and domains from exposure to reconnaissance and automated exploitation, effectively reducing the attack surface. This draft defines the architecture, message format, and workflow of the NHP protocol, outlines its security objectives, and provides guidance for integration into modern network infrastructures and Zero Trust deployments. title: "Network-Infrastructure Hiding Protocol (NHP)" abbrev: "NHP" docname: draft-opennhp-ace-nhp-01 category: informational stream: independent submissiontype: independent number: 00 date: 2025-10-19 v: 1 area: "Security" workgroup: "secdp" keyword: * zero trust * session layer * network obfuscation venue: group: "saag" type: "Independent Submission" mail: "saag@ietf.org (mailto:saag@ietf.org)" arch: "https://mailarchive.ietf.org/arch/browse/secdp/ (https://mailarchive.ietf.org/arch/browse/secdp/)" github: "OpenNHP/ietf-rfc-nhp" latest: "https://OpenNHP.github.io/ietf- rfc-nhp/draft-opennhp-ace-nhp.html (https://OpenNHP.github.io/ ietf-rfc-nhp/draft-opennhp-ace-nhp.html)" |
| | Taxonomy of Composite Attesters |
| |
|
This document further refines different kinds of RFC 9334 Composite Attesters. |
| | Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys |
| |
|
As described in RFC5280, key usages are specified in X.509 certificates using the certificate extensions "Key Usage" and "Extended Key Usage". This document defines an Extended Key Usage (EKU) relating to keys that are dedicated to the purpose of signing attestation evidence as introduced in RFC9334. |
| | Registry and Signature Agent card for Web bot auth |
| |
|
This document describes a JSON based format for clients using [DIRECTORY] to advertise information about themselves. This document describes a JSON-based "Signature Agent Card" format for signature agent using [DIRECTORY] to advertise metadata about themselve. This includes identity, purpose, rate expectations, and cryptographic keys. It also establishes an IANA registry for Signature Agent Card parameters, enabling extensible and interoperable discovery of agent information. |
| | YANG Message Keys for Message Broker Integration |
| |
|
This document specifies a mechanism to define a unique message key for a YANG to message broker integration and a topic addressing scheme based on YANG-Push subscription type and a YANG index defined in this document. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG node, identifier or telemetry message type, by indexing and organizing in Message Broker topics, indexing the information the right way. |
| | Public Key Derived HMAC for JOSE |
| |
| | draft-bastian-jose-pkdh-01.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Paul Bastian, Micha Kraus, Stefan Santesson, Peter Altmann |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines the use of a Diffie-Hellman key agreement (DH-KA) protocol combined with a key derivation function (KDF) to derive a symmetric Message Authentication Code (MAC) key from public information conveyed within a JSON Web Signature (JWS). |
| | The Key List BGP Attribute for NLRI Error handling |
| |
|
RFC 7606 partially revises the error handling for BGP UPDATE messages. It reduces the cases of BGP session reset by defining and using less impactful error handling approaches, such as attribute discard and treat-as-withdraw when applicable. The treat-as-withdraw approach requires that the entire NLRI field of the MP_REACH_NLRI attribute be successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. This is exacerbated by the use of non-key data within NLRI, which introduces parsing complexity and additional error cases. This specification defines a non-transitive BGP attribute, the "NLRI_KEY_LIST attribute", to encode NLRIs as per the format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as- withdraw error-handling approach to be used in case an error in the MP_REACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the NLRI_KEY_LIST attribute appear before the MP_REACH_NLRI (or any other) attribute in an UPDATE message. |
| | IP/ICMP Translation Algorithm |
| |
|
This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. |
| | RTP/SDP for Opus Multistream |
| |
|
This document specifies RTP/SDP signaling for Opus multistream (multi-channel) operation, enabling negotiation of layouts such as 5.1 and 7.1 in real-time communications. It defines an SDP encoding name and format parameters to describe multistream configurations, and specifies Offer/Answer procedures for interoperable negotiation. This document extends the Opus RTP payload format defined in [RFC7587] and reuses the channel-mapping concepts defined for the Ogg container in [RFC7845]. |
| | Private External Message extensions for Messaging Layer Security (MLS) |
| |
|
MLS groups that use private handshakes lose member privacy when sending external proposals. This document addresses this shortcoming by encrypting external proposals using an HPKE public key derived from the epoch secret. It also provides a mechanism to share this key and protect it from tampering by a malicious intermediary. |
| | Ingress Replication BUM flag in VXLAN |
| |
|
This document proposes the allocation of an “Ingress Replication BUM” flag in the VXLAN Flags IANA registry and defines its use in EVPN networks that employ VXLAN tunnels with ingress replication to forward broadcast, unknown and multicast traffic. |
| | Congestion Notification for Pause |
| |
|
This document describes the necessity and feasibility to introduce a mechanism of congestion notification for pause. After receiving the L2 pause frames from the destination data center gateway, the egress provider edge node sends the congestion notifications to the upstream provider nodes and the ingress provider edge node in a format defined in this document. The upstream provider nodes and the ingress provider edge node must pause the forwarding of IP flows identified by the congestion notifications. And then the ingress provider edge node may send the L2 pause frames to the source data center gateway. |
| | A YANG Data Model for network energy efficiency |
| |
|
This document defines the YANG data model for network energy efficiency management, used to maintain network energy efficiency attributes, including device-level, board-level, and port-level. |
| | BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6) |
| |
|
IGP Flexible Algorithm (Flex-Algo) provides a mechanism for IGP nodes to compute the best paths according to a set of constraints in both the topology and computation metrics. Segment Routing over IPv6 (SRv6) can be used as one of the data plane of IGP Flex-Algo. In SRv6 networks, services may be carried across multiple network domains which are under the same administration. For some services, it is expected that the an end-to-end inter-domain path can be computed according to the same constraints (such as low latency) defined by Flex-Algo. This document describes BGP extensions to advertise SRv6 locators as IPv6 prefixes, together with the associated algorithm across the AS boundary. |
| | MPLS Network Action for Deterministic Networking |
| |
|
This document specifies formats and mechanisms for using MPLS Network Actions (MNA) to support Deterministic Networking (DetNet) services, including bounded latency, low loss and in-order delivery. It defines MPLS In-Stack and Post-Stack MNA for carrying DetNet-specific information, such as flow identification, sequence number, and latency information, which are forwarded over an MPLS technology- based network domain. |
| | Proxy Load Balancing in the Remote Authentication Dial In User Service (RADIUS) Protocol |
| |
|
This document describes a few methods which can assist operators of proxies in the in the Remote Authentication Dial In User Service (RADIUS) Protocol. The methods described here improve proxy load balancing and rate limiting, without requiring any changes to the underlying protocol. While these methods have been shown to work in practice, there has been insufficient experience with them to publish this document either as standards track, or as a best current practice. |
| | RPKI Trust Anchor Constraints |
| |
| | draft-nro-sidrops-ta-constraints-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Tom Harrison, Tim Bruijnzeels, Carlos Martinez-Cagnazzo, Mark Kosters, Yogesh Chadee |
| | Working Group: |
Individual Submissions (none) |
|
Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) are commonly configured with five Trust Anchors (TAs), one for each of the Regional Internet Registries (RIRs). Each TA operator is able to make arbitrary RPKI statements about resources independently of the other TA operators: for example, one TA could issue a Route Origin Authorization (ROA) for resources that have actually been assigned to another TA. This document specifies a protocol that allows a set of TAs to make signed statements that assert their consensus as to the resources for which each TA is authoritative. |
| | Path Energy Traffic Ratio API (PETRA) Augmented |
| |
|
This document describes an API to query a network regarding its Energy Traffic Ratio and other energy-related metric for a given network path. |
| | Signaling Alternative Labels for BGP Prefixes |
| |
| | draft-smm-bess-alt-label-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Shyam Sethuram, Mankamana Mishra, MOHANTY Satya, Israel Means, Praveen Ramadenu |
| | Working Group: |
Individual Submissions (none) |
|
A single MPLS label or a label stack is advertised along with an address prefix as part of the NLRI belonging to labeled address families such as Labeled Unicast (RFC 8277), VPN (RFC 4364), etc. This document specifies a method to advertise one or more additional, alternative labels for a set of address prefixes using the Next Hop Dependent Characteristics (NHC) attribute. |
| | OAuth 2.0 Delegated Authorization |
| |
|
Delegated authorization enables a client to delegate a subset of its granted privileges to a subordinate access token (also known as a delegated access token). This mechanism allows the client to securely delegate authorization to a delegated party while maintaining fine-grained control over delegated permissions. |
| | An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems |
| |
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. |
| | Integration of Network Management Agent (NMA) into ACTN-Based Optical Network |
| |
|
With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. |
| | A YANG Data Model for Interface to Network Security Functions (I2NSF) Analytics Interface |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-nmrg-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. |
| | BGP Flow Specification Extension for Feedback Binding |
| |
|
This document specifies a BGP Flow Specification extension that conveys per-route feedback binding for a FlowSpec route using the BGP Extended Community attribute. The proposed mechanism introduces a single Feedback Action, encoded as a Generic Transitive Extended Community, which enables downstream routers to report telemetry information or operational events associated with a FlowSpec rule. The Feedback Action carries parameters including a Feedback Identifier (FID), a window exponent (WINC) that defines the periodic aggregation interval, an event flag, and a scope selector to control where feedback is generated. These parameters are attached to the FlowSpec route and are propagated across AS boundaries unchanged. This document focuses on the signaling aspect; a companion document may define how feedback information is exported as part of a network telemetry framework (e.g., leveraging the BGP Monitoring Protocol (BMP)) or equivalent mechanisms to report periodic and event-driven feedback keyed by the FID. |
| | SRv6 SFC Deployment Options |
| |
|
This document mainly introduces the factors to consider for supporting SRv6 SFC from the aspects of deployment and reliability methods. |
| | Source Address Validation at Intra-domain Network Boundary Using BGP |
| |
|
This document proposes a solution for Source Address Validation (SAV) at the intra-domain network boundary using BGP. Routers at the boundary automatically generate accurate SAV rules by using routing information and SAV-specific information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document also introduces BGP extensions for communicating SAV- specific information among routers at the boundary. |
| | Interface to In-Network Computing Functions (I2ICF): Problem Statement |
| |
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. |
| | A Framework for the Interface to In-Network Computing Functions (I2ICF) |
| |
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. |
| | Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols |
| |
|
This document outlines use cases and desirable properties for integrating remote attestation (RA) capabilities with secure channel establishment protocols, with an initial focus on Transport Layer Security (TLS) v1.3 Handshake. Traditional peer authentication in TLS establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about its current state, including the state of its trusted computing base (TCB). This document explores specific use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. From these use cases, it specifies a set of essential properties the protocol solution must have, including cryptographic binding to the TLS connection, evidence freshness, and flexibility to support different attestation models. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. |
| | Problem Statement of Zero Trust Deployment in Telecom Network Environments |
| |
|
Zero Trust, as a security paradigm, has achieved global practical consensus. However, its large-scale deployment in telecommunications network environments presents unique challenges. Operationally standards tailored to the specific requirements of telecom networks are needed. |
| | Distributed Inference Network (DIN) Problem Statement,Use Cases,and Requirements |
| |
|
This document describes the problem statement, use cases, and requirements for a "Distributed Inference Network" (DIN) in the era of pervasive AI. As AI inference services become widely deployed and accessed by billions of users, applications and devices, traditional centralized cloud-based inference architectures face challenges in scalability, latency, security, and efficiency. DIN aims to address these challenges by leveraging distributed edge-cloud collaboration, intelligent scheduling, and enhanced network security to support low- latency, high-concurrency, and secure AI inference services. |
| | WIMSE Applicability for AI Agents |
| |
|
This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. |
| | Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens |
| |
|
This document defines a profile for using OAuth Transaction Tokens in Agent-to-Agent (A2A) communication scenarios. The profile specifies how A2A call chain context can be embedded within Transaction Tokens to maintain agent identity, authorization context, and execution flow across distributed agent workloads within trusted domains. |
| | Hashing Authentication Credentials in EDHOC |
| |
|
This document defines a COSE header parameter which signals that an authentication credential is replaced by the hash of the authentication credential in the protocol message computations. This further relaxes the need for transporting authentication credentials in EDHOC, which reduces protocol message sizes and improves performance in constrained networks. |
| | Model Context Protocol (MCP) Extensions for Network Equipment Management |
| |
|
The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework for interaction between AI applications and external context sources. This document specifies minimal extensions that allow network equipment (routers, switches, etc.) to act as MCP servers while controllers act as MCP clients. New capability tokens, tools, resources, prompts, and error codes are defined without breaking existing MCP implementations. |
| | SRv6 OAM Deployment Consideration |
| |
|
This document introduces common issues to consider when implementing SRv6 OAM, as well as various solutions. |
| | 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. |
| | Addressing Recommendations for SRv6 |
| |
|
This document describes SRv6 addressing for NEXT-CSID locator format. It introduces concepts of Blocks, Sets, and Node IDs, and explains how summarization boundaries and flexible algorithm support can be implemented for both small and large networks. |
| | Motivations and Problem Statement of Agentic AI for network management |
| |
|
This document outlines the key objectives of introducing Agentic AI to the field of network management and highlights the fundamental issues with existing technologies that must be addressed to achieve these goals. It emphasizes the necessity for relevant groups within the IETF/IRTF and presents the core technological areas requiring standardization. The aim of Agentic AI is to facilitate a paradigm shift in which multiple autonomous AI agents collaborate to fully automate network operation, management and security. |
| | AI Agent Architecture for DTN Digital Twin Network |
| |
|
This document proposes an AI agent architecture for Digital Twin Network (DTN) that integrates AI agents with digital twin technology. The architecture extends the traditional DTN architecture by incorporating autonomous AI agents at each component level, enabling more intelligent and adaptive network management capabilities. |
| | Optimized Use of BIER in AIML Data Centers |
| |
|
Use of multicast in AI Data Centers (AIDC) is getting attention for efficient large-scale distribution of the same data to many receivers, given the collectives like All2All and AllReduce. Emerging technologies like In Network Compute(INC) can also benefit from using in-network-distribution of the packets by offloading the distribution of the flows to the network. Given the bursty nature of short-lived all2all flows, BIER is a very good multicast technology for AIDC because it does not need the per-establishment of the multicast tree states. This document discusses further optimization of BIER use in AIDC or similar deployment scenarios, and updates RFC4604 by specifying an IGMP/MLD extension for sources to report receiver information to the First Hop Routers. The extension can be useful and is only needed when the source cannot impose the BIER encapsulation. |
| | Framework for AI Agent Networks |
| |
|
This document defines the framework of AI agent networks based on Agent Network Protocol (ANP) protocol. [ANP] It provides the basic functions that needs to support AI agent communication in the AI agent networks within the trust domain. |
| | Automatic Network Congestion Relief in GeneRic Autonomic Signaling Protocol (GRASP) |
| |
|
This draft defines a method for automatic congestion relief using the Grasp protocol. In operator networks, in response to network failures such as fiber optic cable faults and optical module malfunctions, network devices can automatically respond and achieve real-time self-healing, thereby ensuring the stable operation of the network. |
| | A Standard for Claiming Transparency and Falsifiability |
| |
| | draft-laurie-tmif-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Ben Laurie, Tiziano Santoro, Pauline Anthonysamy, Sarah de Haas |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a transparency metadata interface format that allows a system to make claims about its levels of transparency and falsifiability. 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/sarahdeh/draft-TMIF. |
| | Precise ECN in WAN |
| |
|
This draft defines the precise ECN during used in WAN. With the growing demand for AI computing power, the computational capacity of a single Artificial Intelligence Data Center (AIDC) can no longer meet the requirements of large-scale model training. This has led to the emergence of cross-AIDC distributed model training, driving the need for transmitting RoCEv2 packets over WAN networks. AI training is highly sensitive to network packet loss, where even minimal packet loss can significantly degrade training efficiency. Additionally, elephant flows and extreme concurrent traffic impose higher demands on network performance. ECN achieves active feedback of network congestion by setting ECN flag bits in the header of IP packets, which is an effective traffic control method. RFC6040 introduces the application of ECN in WAN. However, due to the much higher end-to-end delay in WAN than in DC, and the frequent occurrence of instantaneous traffic bursts in WAN, it is easy to trigger ECN at the wrong time. This draft focuses on the precise use of ECN in WAN, by introducing different reactions of ECN in different WAN transmission scenarios |
| | Single Signature KeyPackages |
| |
|
Single Signature KeyPackages improve the overhead of creating, transmitting and verifying MLS KeyPackages by removing one signature. |
| | Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems |
| |
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) in Cooperative Intelligent Transportation Systems (C-ITS). For example, in the context of Vehicle-to-Everything (V2X) communications, efficient management of Vehicle-to-Vehicle (V2V) communications and their integration with C-ITS can greatly benefit from in-network computing. By leveraging ICFs, it becomes possible to optimize real- time communication, streamline traffic management, and enhance data processing and security services at the network edge. Moreover, by incorporating the Agent-to-Agent (A2A) communication paradigm, intelligent agents within vehicles, Roadside Units (RSUs), and network domains can directly collaborate to negotiate resources, exchange contextual information, and coordinate computing tasks, enabling adaptive and scalable orchestration across multi-domain C-ITS environments. |
| | Service Instance Deployment based on Integrated Network and Compute Metrics |
| |
|
The deployment of service instances across distributed interconnected edge-cloud environments can be optimized in terms of performance expectations and Service Level Objectives (SLOs) satisfaction when performed taken into account both network and compute metrics. In order to do so, this document primarily concentrates on existing standardized mechanisms, namely ALTO and CATS, to facilitate such integration of metrics. The ALTO protocol can be extended to expose compute metrics from a cloud manager to a network orchestrator or as part of the network and cost maps, enabling improved deployment of compute service instances based on joint awareness of both network and computing information. This document proposes protocol extensions, workflows, and operational considerations for ALTO enhancements using CATS metrics. |
| | Definition for BMP Multiple Peer Header |
| |
|
This document proposes a format of multiple peer header for aggregating BMP messages. It can be used to compress multiple BMP messages with per-peer header into one aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead. |
| | OAM for EVPN over SRv6 |
| |
|
RFC 9489 describes Operation, Administration, and Maintenance (OAM) mechanisms for detecting data plane failures using Label Switched Path (LSP) Ping in MPLS-based Ethernet VPN (EVPN) networks. However, there is no effective OAM mechanism for detecting data plane failures in SRv6-based EVPN networks. This document proposals OAM mechanisms for SRv6-based EVPN networks. |
| | An Integrated Security Service System for 5G Networks using an I2NSF Framework |
| |
|
This document presents an integrated framework for automated security management in 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system leverages Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated into enforceable network and application policies. Network-level policies are delivered to 5G core components via the Network Exposure Function (NEF), while application-level policies are enforced directly on a User Equipment (UE) through distributed IBN Controllers. This architecture supports adaptive, context-aware, and distributed policy enforcement, enabling real-time response to dynamic edge conditions and user mobility scenarios such as handovers. By integrating closed-loop monitoring and analytics, the system ensures consistent and autonomous security across heterogeneous 5G environments. |
| | Distribute ARN6 ID by DHCP |
| |
|
This document describes a method for assigning ARN6 ID through DHCPv6. |
| | Peer Capability Update Notification in BGP Monitoring Protocol (BMP) |
| |
|
When BGP Dynamic Capability is supported, dynamic updates of capabilities are allowed over an established BGP session. At present, after the BGP session is established, the monitored router sends a BMP Peer Up Notification message first, containing the initial capabilities. If BGP Dynamic Capability is supported, using BMP Peer Up Notification messages to report subsequent capability changes for a BGP session becomes inappropriate. This document defines a new Peer Capability Update Notification message type in BMP to report peer capability changes. |
| | Hybrid Digital Signatures with Strong Unforgeability |
| |
|
This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF- CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security. In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure. |
| | IPv6-Resolved IPv4 Gateway |
| |
|
This document requests the allocation of a new IPv4 special-purpose address from the IANA IPv4 Special-Purpose Address Registry. The proposed address, 192.0.0.11/32, is intended to serve as a signal to IPv4 hosts in IPv6-only networks that the link-layer resolution for the default gateway should be derived from the IPv6 default gateway learned via IPv6 Router Advertisements and Neighbor Discovery. This approach enables IPv4 communication without requiring IPv4 subnets or the use of ARP. It maintains backward compatibility with existing IPv4 host software that expects a default gateway IP address, while avoiding the need to implement legacy link-layer protocols. |
| | MPLS for AIDC Probing |
| |
|
This document describes a method for using Multi-Protocol Label Switching (MPLS) encapsulation to perform scalable and vendor- agnostic network probing within AI/ML data centers. The goal is to detect and isolate gray failures—non-deterministic hardware and software faults—in large-scale lossless networks. The approach enables targeted probing at per-link and per-node granularity, independent of IP/BGP control plane operation, and is extensible to Various CLOS topologies. |
| | Mothma: Generic Instantiated PQ/T Hybrid Signatures |
| |
|
This document specify Mothma as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Digital Signatures. The goal is to provide a generic hybrid signature pattern that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on combinations of the traditional EdDSA, ECDSA and RSA methods with the post-quantum methods of ML-DSA, SLH-DSA, XMSS and LMS. |
| | Test Vectors for CBOR Encoded X.509 (C509) Certificates |
| |
|
This document contains examples of CBOR encoded X.509 (C509) certificates, certificate (signing) requests, and certificate request templates. |
| | Extension to Connect-IP for static IP header compression |
| |
|
This document specifies an extension for IP header compression when using Connect-IP proxying. |
| | Unified Optical Networks and AI Computing Orchestration (UONACO) Problem Statement,Use Cases and Requirements |
| |
|
Distributed artificial intelligence (AI) computing is increasingly deployed across geographically dispersed AI data centers (AIDCs) to meet the scale and performance demands of modern AI workloads. In such environments, the efficiency of distributed training, inference, and remote service access depends critically on tight coordination between optical transport networks and compute orchestration systems. However, today's infrastructure operates with isolated control planes: optical networks lack awareness of dynamic compute requirements, while compute schedulers have no visibility into real- time network conditions such as latency, bandwidth, or congestion. This decoupling leads to suboptimal resource utilization, degraded job performance, and inefficient scaling. This document presents the problem statement, outlines three representative use cases—distributed AI training, distributed AI inference, and remote AI service access—and specifies the requirements for Unified Optical Networks and AI Computing Orchestration (UONACO). The goal is to enable bidirectional awareness, joint resource abstraction, and synchronized control across the compute-optical boundary, thereby supporting intent- driven, end-to-end provisioning of AI services over wide-area optical infrastructures. |
| | Remote Attestation with Exported Authenticators |
| |
| | draft-fossati-seat-expat-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Thomas Fossati, Muhammad Sardar, Tirumaleswar Reddy.K, Yaron Sheffer, Hannes Tschofenig, Ionut Mihalcea |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. |
| | A Control Framework for Unified Optical Networks and AI Computing Orchestration (UONACO) |
| |
|
This document presents the control framework for Unified Optical Networks and AI Computing Orchestration (UONACO). Specifically, it defines the AI computing service model over wide-area networks, outlines the UONACO control architecture, identifies a set of UONACO components and interfaces, and describes their interactions. |
| | Anonymous Tokens with Hidden Metadata |
| |
| | draft-yun-cfrg-athm-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Cathie Yun, Christopher Wood, Mariana Raykova, Samuel Schlesinger |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Anonymous Tokens with Hidden Metadata (ATHM) protocol, a protocol for constructing Privacy Pass like tokens with hidden metadata embedded within it unknown to the client. |
| | Anonymous Token with Hidden Metadata Privacy Pass Issuance and Authentication Protocols |
| |
| | draft-yun-privacypass-athm-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Cathie Yun, Christopher Wood, Mariana Raykova, Samuel Schlesinger |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Tokens with Hidden Metadata (ATHM) protocol. |
| | DNS Protocol Modifications for Delegation Extensions |
| |
|
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document describes modifications to the Domain Name System (DNS) protocol to permit a range of resource record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. |
| | EVPN Multi-Active Multihoming |
| |
|
EVPN supports All-Active and Single-Active multihoming, where either all multihoming PEs are active or only one is active. In some situations, it is desired to support Multi-Active with multiple yet not all active PEs. This document specifies the Multi-Active multihoming - some multihoming PEs are in All-Active mode while others are in Single-Active mode on the same multihoming Ethernet Segment, and ingress PEs load-balance to those in All-Active mode. |
| | HTTP Signature Component for TLS Channel Binding |
| |
|
A derived component is specified for HTTP Message Signatures that binds the signature to the underlying secure channel (TLS over TCP or QUIC), thereby ensuring a signed message transmitted over one channel cannot be retransmitted over another. The component consists of key material exported from TLS. |
| | Defend the World from IoT Remote-threats & Malware |
| |
|
Internet of Things (IoT) devices are commonly added to home networks without fully understanding which services (hosts, ports, protocols) are being provided or consumed for those devices to operate. As a result, they are essentially unmanaged threats with full access to that network and the internet. The Defend the World from IoT Remote- threats & Malware (DWIRM) extension to DHCP provides a framework for IoT devices to negotiate services that the local router in turn enforces as policy. |
| | Metadata Constrained Distribution |
| |
|
This document defines the Metadata-Filter (MDF) Subsequent Address Family Identifier (SAFI). A BGP speaker uses MDF to signal its lack of interest in receiving service metadata attributes on routes that carry specified Route Targets (RTs), while leaving reachability unchanged. |
| | Model Context Protocol over Media over QUIC Transport |
| |
|
This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP is a protocol that enables seamless integration between language model applications and external data sources and tools. MOQT provides efficient, low-latency, publish-subscribe media delivery over QUIC and WebTransport. This specification describes the mapping of MCP messages onto MOQT objects and defines the procedures for establishing and maintaining MCP sessions over MOQT. |
| | Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol |
| |
|
This document specifies how the Agent-to-Agent (A2A) protocol can be transported over Media over QUIC Transport (MOQT). MOQT provides a publish/subscribe model over QUIC that enables efficient real-time communication between AI agents, supporting the A2A protocol's requirements for discovery, negotiation, and collaboration while leveraging MOQT's streaming capabilities and built-in prioritization mechanisms. |
| | SRP Remove All Services EDNS(0) option |
| |
|
This document describes a new EDNS(0) option for an SRP Update to remove all previously registered services for a hostname before adding new services for that same hostname. This allows an SRP requester to replace all its previous service registrations with new ones using a single SRP Update. |
| | A code to describe satellite constellations |
| |
|
When considering a satellite constellation forming a non-terrestrial network, the characteristics of this constellation heavily influences the network topology it forms. To improve the analysis of such non- terrestrial networks across various tools developed by the network community, this document proposes a notation to describe common constellation patterns. In addition, this document may serve as an introduction to satellite constellations for IETF participants. |
| | MIMI Identifiers |
| |
|
TODO Abstract |
| | Reliability Considerations for Delay-Tolerant Networks |
| |
| | draft-birrane-dtn-rel-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Edward Birrane, Sabrina Pellegrini, Alex White |
| | Working Group: |
Individual Submissions (none) |
|
This document provides definitions and concepts related to network reliability as adapted to the Delay-Tolerant Networking (DTN) architecture where there is no presumption of simultaneous end-to-end paths between message sources and destinations. |
| | Automated Certificate Management Environment (ACME) Profile Sets |
| |
|
This document defines how an ACME Server may indicate collections of related certificate profiles to ACME Clients. |
| | A YANG Model for SmartPDU Monitoring and Control |
| |
|
This document defines a YANG data model for Smart Power Distribution Units (SmartPDUs). SmartPDUs extend traditional PDUs by incorporating telemetry and remote control functions that enable detailed monitoring and management of energy consumption. Current SmartPDU solutions are largely proprietary, exposing heterogeneous APIs and data formats that complicate integration and automation. The proposed YANG model provides a vendor-neutral framework for configuration, monitoring, and control of intelligent power distribution systems. An initial version of the proposed YANG data model has been developed during the GREEN Framework and Use Cases project at the Hackathon performed during IETF 123 (July 2025). |
| | Equipment Capability Application |
| |
|
This document applies the generalized capability principles to the description of equipment (a physical thing) with applied data (configuration state and code (software, firmware etc.)) and shows how such capability specifications integrate with base inventory and entitlement models as defined in Network Inventory, Software Extension and Entitlement YANG models. The approach is examined by example, focusing on how the potential capabilities of each equipment type-version with applied data are described, how these map to entitlements (licensed or policy- controlled subsets of capabilities), and how they are instantiated as inventory items. The explanation covers both the capabilities of equipment in terms of physical properties and the capabilities of equipment with applied data in terms of resultant emergent functionality. |
| | Generalized Capability Principles |
| |
|
This document introduces a framework for capability modeling based on the specification and refinement principles established in ITU-T G.7711 Annex G (also published as ONF TR-512.7 see latest release) and the modeling boundaries work documented in draft-davis-netmod- modelling-boundaries. The framework defines how component–system capabilities can be explicitly described and refined via a process of pruning, refactoring, and occurrence formation. These capability definitions can target detailed operational considerations, system interactions, licensing, abstract product declarations, or sales and marketing. The framework supports modular, layered, and fractal declarations of networked behavior, and provides a foundation for a suite of future IETF drafts aligned with ongoing work on photonic plug manifests, entitlement/licensing, IVY equipment modeling, energy/thermal considerations and related domains. |
| | Privacy Pass Issuance Protocol for Anonymous Credit Tokens |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Credit Tokens (ACT) protocol. |
| | x509 Decentralized Identifier |
| |
| | draft-birkholz-did-x509-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Maik Riechert, Antoine Delignat-Lavaud, Henk Birkholz, Amaury Chamayou |
| | Working Group: |
Individual Submissions (none) |
|
Some abstract |
| | HMAC Based Hybrid Key Combiners for Multiple Keys |
| |
|
As a fundamental building block in security protocols, a key combiner is used to combine two or more input cryptographic keys, some potentially compromised, into a single pseudorandom output key. Most of the existing key combiners are for two input keys. This draft specifies two proveably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys are produced by different algorithms or even different approaches [RFC9370], [ETSI25]. Namely, here the input keys can be two or more, and the combined output key remains pseudorandom if at least one of the input keys is secure, i.e., uniformly random and unknown to an attacker. The two constructions, called HKCv1 and HKCv2, are based on the extract-then- expand paradigm of HMAC (Keyed-Hashing for Message Authentication) [RFC2104]. HKCv1 is designed for simultaneously available input keys using concatenation, while HKCv2 is tailored for scenarios where input keys arrive incrementally, using an iterative HMAC structure. [EDNOTE: .... ] |
| | Protocol for Crowd Sourcing Air Domain Awareness |
| |
|
This document standardizes an architecture to enable trust to sensors that provide Air Domain Awareness. Broadcast Remote ID is used as the primary example to define data models and methods used. |
| | Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios |
| |
|
Encrypted Client Hello (ECH) improves destination privacy by encrypting the Server Name Indication in TLS, but the customer's source identity-- typically the IP address and network metadata-- remains observable to intermediaries such as CDNs, hosting providers, and recursive resolvers. This document introduces the _Customer- Facing Relay (CFR)_, a lightweight, transport-agnostic relay operated by access providers to decouple customer identity from encrypted destinations. By forwarding opaque encrypted payloads (TCP or UDP) without terminating TLS or QUIC, a CFR complements ECH encryption to strengthen source privacy and reduce metadata correlation. |
| | Authenticated ECH Config Distribution and Rotation |
| |
|
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them without a certificate for the public name, limiting deployment flexibility. This document specifies an authenticated ECH configuration update mechanism. Servers can deliver signed ECH configurations during the TLS handshake, allowing clients to authenticate and immediately use them for retry. The mechanism decouples ECH key distribution from transport, enabling the same signed configuration to work via DNS or TLS delivery. |
| | Fine-Grained Flow Control Backpressure Mechanism for Wide Area Networks |
| |
|
This document specifies a fine-grained flow control backpressure mechanism for Wide Area Networks (WANs). The mechanism enables precise congestion notification and flow control at tenant or task granularity through extended network protocols and controller- assisted path discovery. It addresses the limitations of traditional flow control mechanisms in WAN environments by providing intelligent backpressure with detailed congestion information, with specific applicability in SRv6-based networks. |
| | Metric Normalize for IGP Flex-algo |
| |
|
When multiple links in a network have the same metric, they can serve as ECMP equivalent links for load balancing during forwarding. However, slight fluctuations in metric values can prevent the formation of ECMP equivalent links, leading to the idle state of suboptimal links and thus wasting bandwidth resources. This document proposes a method for normalizing metrics, allowing the slight fluctuations across multiple links to be adjusted so that the resulting calculated metrics become identical. This enables the formation of ECMP equivalent links, facilitating load distribution during forwarding. |
| | Applicability Statement for IETF Core Email Protocols |
| |
|
Electronic mail is one of the oldest internet applications in active use. The protocols and formats for mail transport and message formats have evolved slowly over the years. This Applicability Statement describes interaction with newer protocols. [Provided as a diff to the WG document] |
| | Base YANG Data Model for NVO3 Protocols |
| |
| | draft-ietf-nvo3-yang-cfg-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Ran Chen, Zhaokun Ding, Fengwei Qin, Reshad Rahman, Bing Liu |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document describes the base YANG data model that can be used by operators to configure and manage Network Virtualization Overlay protocols. The model is focused on the common configuration requirement of various encapsulation options, such as VXLAN, NVGRE, GENEVE and VXLAN-GPE. Using this model as a starting point, incremental work can be done to satisfy the requirement of a specific encapsulation. The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA). |
| | OAuth 2.0 for First-Party Applications |
| |
|
This document defines the Authorization Challenge Endpoint, which supports a first-party client that wants to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. |
| | Guidelines for Characterizing "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates [RFC6291] by adding to the guidelines for the use of the term "OAM". It does not modify any other part of [RFC6291]. |
| | A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests |
| |
|
This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes. |
| | Multipath Support for IGMP/MLD Proxy |
| |
|
This document specifies the framework to support multipath reception in Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed mechanism allows IGMP/ MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. It defines static configuration methods for associating upstream interfaces with channel identifiers and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. |
| | Anonymous Rate-Limited Credentials |
| |
|
This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. |
| | qlog: Structured Logging for Network Protocols |
| |
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | QUIC event definitions for qlog |
| |
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | HTTP/3 qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | Concise Reference Integrity Manifest |
| |
| | draft-ietf-rats-corim-09.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. |
| | Concise Selector for Endorsements and Reference Values |
| |
| | draft-ietf-rats-coserv-02.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Paul Howard, Thomas Fossati, Henk Birkholz, Shefali Kamal, Giridhar Mandyam, Ding Ma |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. |
| | Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) |
| |
| | draft-ietf-sidrops-bar-sav-08.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery |
| | Working Group: |
Source Address Validation in Intra-domain and Inter-domain Networks (savnet) |
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. |
| | Gap Analysis,Problem Statement,and Requirements for Inter-Domain SAV |
| |
|
This document provides a gap analysis of existing inter-domain source address validation mechanisms, describes the problem space, and defines the requirements for technical improvements. |
| | RPKI Publication Server Best Current Practices |
| |
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. |
| | Trust and security considerations for Structured Email |
| |
|
This document discusses trust and security considerations for structured email and provides recommendations for message user agents on how to deal with structured data in email messages. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Structured Email Working Group mailing list (sml@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sml/. Source for this draft and an issue tracker can be found at https://github.com/arnt/sml-trust. |
| | Selective Disclosure CBOR Web Tokens (SD-CWT) |
| |
| | draft-ietf-spice-sd-cwt-05.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. |
| | Use Cases for SPICE |
| |
| | draft-ietf-spice-use-cases-03.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Brent Zundel, Michael Prorock, Michael Jones |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation. |
| | YANG Data Model for Segment Routing Policy |
| |
| | draft-ietf-spring-sr-policy-yang-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Tarik Saleh, Syed Raza, Shunwan Zhuang, Satoru Matsushima, Vishnu Beeram |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. |
| | YANG Data Model for SRv6 Static |
| |
| | draft-ietf-spring-srv6-yang-static-00.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Syed Raza, Jaganbabu Rajamanickam, Satoru Matsushima, Pingping Yu, Xufeng Liu |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) Static for provisioning static SIDs. The SRv6 Static model augments the SRv6 base YANG model with specific data to configure and manage SRv6 Static SID(s). The YANG module in this document conform to the Network Management Datastore Architecture (NMDA). |
| | Guidance on RESTful Design for Internet of Things Systems |
| |
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-06.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-19.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| | Scalability Considerations for Network Resource Partition |
| |
| | draft-ietf-teas-nrp-scalability-08.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| | IETF Network Slice Controller and its Associated Data Models |
| |
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. |
| | Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases |
| |
|
This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. |
| | The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 |
| |
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. |
| | Configuring UDP Sockets for ECN for Common Platforms |
| |
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| | Using off-path mechanisms for exposing Time-Variant Routing information |
| |
|
Time-Variant Routing (TVR) involves predictable, scheduled changes to network topology elements such as nodes, links, and adjacencies that impact routing behavior over time. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). This document proposes mechanisms for exposing TVR information to both internal and external applications, focusing on off-path solutions that decouple the advertisement of scheduled changes from the routing control plane signaling. |
| | IPv6-Mostly Networks: Deployment and Operations Considerations |
| |
|
This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). |
| | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. |
| | The WebTransport Protocol Framework |
| |
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. |
| | WebTransport over HTTP/3 |
| |
|
WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. |
| | WebTransport over HTTP/2 |
| |
| | draft-ietf-webtrans-http2-13.txt |
| | Date: |
20/10/2025 |
| | Authors: |
Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie |
| | Working Group: |
WebTransport (webtrans) |
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. |
| |
|
| |
| | Semantic Definition Format (SDF) modeling for Digital Twin |
| |
| | draft-ietf-asdf-digital-twin-02.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Hyunjeong Lee, Jungha Hong |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-29.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. |
| | EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols |
| |
|
The existing EVPN multi-homing load-balancing modes do not adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, etc. This document defines a new multi-homing mechanism to support these loop-preventing Layer-2 protocols. |
| | BGP link bandwidth extended community use cases |
| |
| | draft-ietf-bess-ebgp-dmz-08.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Stephane Litkowski, MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, Reshma Das |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
BGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations. |
| | CDNI Delivery Metadata |
| |
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior for downstream CDN (dCDN) node selection, and request routing modes of traffic delegation. |
| | CDNI Metadata Expression Language |
| |
|
This document specifies the syntax and provides usage examples for an expression language to be used within Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| | CDNI Processing Stages Metadata |
| |
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| | CDNI Source Access Control Metadata |
| |
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-17.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). |
| | DULT Threat Model |
| |
|
Lightweight Location-tracking Tags are in wide use to allow users to locate items. These Tags function as a component of a Crowdsourced Network in which Devices belonging to other network users (e.g., phones) report which Tags they see and their location, thus allowing the Owner(s) of the Tag to determine where their Tag was most recently seen. While there are many legitimate uses of these Tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect Unwanted Tracking must incorporate an understanding of the Unwanted Tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of Unwanted Tracking and potential attacks against Detection of Unwanted Location Tracking (DULT) protocols. The document defines what is in and out of scope for the Unwanted Tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect Unwanted Tracking. |
| | AS Path Prepending |
| |
| | draft-ietf-grow-as-path-prepending-17.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Mike McBride, Doug Madory, Jeff Tantsura, RASZUK Robert, Hongwei Li, Jakob Heitz, Gyan Mishra |
| | Working Group: |
Global Routing Operations (grow) |
|
Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet. |
| | BMP Loc-RIB: Peer address |
| |
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. |
| | Procedures for Handling Liaison Statements to and from the IETF |
| |
| | draft-iab-rfc4053bis-00.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Mirja Kuehlewind, Suresh Krishnan, Qin WU |
| | Working Group: |
Internet Architecture Board (iab) |
|
This document describes the procedures for generating and handling liaison statements between the IETF and other SDOs, so that the IETF can effectively collaborate with other organizations in the international standards community. |
| | On-Path Telemetry for Active Performance Measurements |
| |
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | Asymmetric Manifest Based Integrity |
| |
|
This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. |
| | Discovery Of Restconf Metadata for Source-specific multicast |
| |
|
This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. |
| | Circuit Breaker Assisted Congestion Control |
| |
|
This document specifies Circuit Breaker Assisted Congestion Control (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate metadata about multicast channels from senders to intermediate network nodes or receivers. The circuit breaker behavior is defined as a supplement to receiver driven congestion control systems, to preserve network health if misbehaving or malicious receiver applications subscribe to a volume of traffic that exceeds capacity policies or capability for a network or receiving device. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-05.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server |
| | Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| | Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
| |
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| | Multiple IPv4 - IPv6 address mapping translator (M46T) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| | Multi-Stage Transparent Server Load Balancing |
| |
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| | Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
| |
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| | Extending ICMPv6 for SRv6-related Information Validation |
| |
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. |
| | An EAT-based Key Attestation Token |
| |
| | draft-bft-rats-kat-06.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Mathias Brossard, Thomas Fossati, Hannes Tschofenig, Henk Birkholz, Ionut Mihalcea |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. |
| | BGP Flow Specification for Source Address Validation |
| |
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules. |
| | Kademlia-directed ID-based Routing Architecture (KIRA) |
| |
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | A Profile for Autonomous System Relationship Authorization (ASRA) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA. |
| | Provider Independent Addresses Aggregation |
| |
|
This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network or Intent-based Networking, and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. |
| | A YANG Data Model of Performance Management Streaming |
| |
|
This document provides a YANG data model of performance management streaming from network equipment to clients. It defines PM measurement methods, event notifications, generic PM parameters and streaming subscriptions. Additionally, it includes a YANG module for PM interval capabilities discovery, enabling clients to understand supported sampling and measurement intervals before configuring PM measurements. |
| | Computing Energy Consumption Path in Segment Routing Networks |
| |
|
This document describes a method for computing energy consumption paths in Segment Routing (SR) networks, aiming to optimize network traffic routing for energy efficiency, including procedures for energy consumption data collection, path calculation, and issuance, as well as considerations for data plane implementation in both MPLS SR and SRv6 networks. |
| | A YANG Data Model for CMIS Access and Control |
| |
|
This document provides a YANG data model to access to and control CMIS for managing pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside. CMIS has custom pages which enables to be defined by the module vendor for its own usage, and allows to extend the uses of the optics devices. |
| | OAuth 2.0 Refresh Token and Authorization Expiration |
| |
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. |
| | BMP Sequence Number,Timestamp and Flags TLVs |
| |
|
This document defines a Timestamp TLV that carries a timestamp describing one of multiple possible events related to the BMP message. It also defines a Sequence Number TLV which carries the sequence number of the BMP message for the current BMP session. Finally, this document defines an Extended Flags TLV that replaces the Flags field of the Per-Peer Header, allowing more flags to be allocated in BMP. |
| | Fast Notification for tunnel-based lossless RDMA transmission in WAN |
| |
|
With the rapid development of Large Language Models (LLMs), many emerging AI services require lossless transmission of RDMA packets over tunnels in Wide Area Network(WAN). To meet the stringent performance demands of these services, WAN should support the real- time network state notification to ensure high throughput, low latency, and zero packet loss. The current reactive notification mechanisms are limited by responsiveness, coverage, and operational efficiency. Therefore, a faster and proactive notification mechanism is needed to enable more responsive Traffic Engineering (TE) and Load Balancing (LB). This draft describes typical scenarios for transmitting RDMA packets over WAN tunnels, specifies the fast notification framework to support key TE areas (e.g., congestion control, protection, and load balance), and defines the packet format for fast notification. |
| | Generative AI for Intent-Based Networking |
| |
| | draft-cgfabk-nmrg-ibn-generative-ai-01.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Pietro Cassara', alberto_gotta, Giuseppe Fioccola, Aldo Artigiani, Riccardo Burrai, Emiljan Kolaj, Marco Martalo', Virginia Pilloni |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. |
| | A YANG Data Model for Reporting Utilization Scores in ISAC |
| |
|
This document defines a basic YANG data model to report sensing measurements utilization score (US) in Integrated Sensing and Communication (ISAC) systems. The score quantifies the resource impact of different sensing measurements, including compute, memory, storage, energy, and latency. The model supports per-measurement telemetry reporting. |
| | Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) |
| |
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC8588. |
| | Prefix-Preserving Encryption for URIs |
| |
|
This document specifies URICrypt, a deterministic, prefix-preserving encryption scheme for Uniform Resource Identifiers (URIs). URICrypt encrypts URI paths while preserving their hierarchical structure, enabling systems that rely on URI prefix relationships to continue functioning with encrypted URIs. The scheme provides authenticated encryption for each URI path component, preventing tampering, reordering, or mixing of encrypted segments. |
| | Filter of Configuration Change Notifications |
| |
|
This document extends the YANG-Push notification subscription mechanism for on-change to reduce unnecessary reporting after an on- change YANG-Push notification is generated. |
| | Service Affinity Solution based on Transport Layer Security (TLS) |
| |
|
This draft proposes a service affinity solution between client and server based on Transport Layer Security (TLS). An extension to Transport Layer Security (TLS) 1.3 to enable session migration. This mechanism is designed for modern network architectures, particularly for multi-homed servers that possess multiple network interfaces and IP addresses. Comparing to the existing solutions such as maintaining the customer- based connection status table in network devices, HTTP redirection and DNS redirection, this solution can avoid the waste of resources caused by saving a large amount of customer status data in the network devices, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing- aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources. |
| | CBOR Pointer: Selecting Elements of Concise Binary Object Representation (CBOR) Documents |
| |
|
CBOR Pointer is a syntax to identify a single CBOR value from a CBOR document with an arbitrarily complex nested structure. It is analogous to JSON Pointer. |
| | Hardware-Rooted Attestation for Precision Time Protocol: Verifiable Residency and Proximity proofs |
| |
|
This document defines an extension to Precision Time Protocol (PTP) that provides per-event cryptographic attestation using non-exportable asymmetric keys resident in TPMs or HSMs, and an optional PTP-in-HTTPS/MTLS encapsulation mode. When combined with freshness and multi-observer correlation, this provides defensible proof of proximity for timing events. PTP-in-HTTPS/MTLS adds end-to-end confidentiality for timing payloads across untrusted fabrics. NOTE: This note is a placeholder to show the correct structure that avoids the "setup generated" error (Line 53). All paragraphs inside a note must be separated by a blank line. *setup generated* |
| | BGP best path next-hop selection enhancements |
| |
|
BGP [RFC4271] has originally been designed to carry IPv4 routing information over the Internet. IP routing being “hop-by-hop” in nature, [RFC4271] defines the NEXT_HOP attribute which purpose is to carry the address of the next router to send the IP packet to. In BGP, the next-hop may not be a directly connected router, hence, when evaluating paths, BGP needs to figure out if the next-hop is resolvable and, when needed, needs to figure out what is the internal cost to reach this next-hop. The incremental use of tunneling technologies to carry traffic between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6…) may violate the assumption that the address carried in the NEXT_HOP attribute is representative of the actual forwarding next-hop. These technologies decouple the BGP control-plane's view of the next-hop from the data- plane's actual forwarding endpoint. This document describes the problems that arise from this decoupling. These problems include sub-optimal path selection, incorrect resolvability tracking of the forwarding path leading to traffic drop or misrouting, and others. This document proposes some modification of BGP path selection procedures to accommodate these use cases. |
| | Agent Directory Service |
| |
|
The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. |
| | Log More Routing Events in the BGP Monitoring Protocol (BMP) |
| |
|
The Route Event Logging (REL) message is defined in [I-D.ietf-grow-bmp-rel] and is used to report event-driven data to the BMP Server from the monitored routers. This document defines more event-driven data for BGP FlowSpec RFC8955 [RFC8956] and BGP SR Policies [I-D.ietf-idr-sr-policy-safi]. |
| | Model for distributed authorization policy sharing |
| |
|
This document defines mechanisms and conventions for the representation and sharing of authorization policies in distributed and automated environments. It specifies the foundational elements required to express policies in a consistent, machine-readable, and interoperable manner, enabling fine-grained control and context-aware evaluation. The framework supports the complete policy lifecycle, including creation, validation, versioning, distribution, and decommissioning, with YANG serving as the canonical representation format. It also establishes the relationship between policy representation and the structure of tokens used in enforcement and authorization exchanges, ensuring coherent and dynamic policy evaluation across heterogeneous systems. |
| | Geographic Attestation Results |
| |
|
Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. This document is about encoding a variety of geographical conclusions in an Attestation Result. |
| | OAuth 2.0 Entity Profiles |
| |
|
This specification introduces Entity Profiles as a mechanism to categorize OAuth 2.0 entities—clients and subjects—based on their operational context. Entity Profiles provide structured descriptors for the client initiating the OAuth flow and the subject represented in tokens. This document defines new JWT Claim names and metadata parameters for use in access tokens, ID tokens, token introspection responses, dynamic client registration, and Authorization Server metadata. |
| | LISP Delegated Mappings |
| |
|
The LISP protocol with its inherent decoupling of control-plane and data-plane, offers the flexibility to support modern networking paradigms. This document specifies how to use the LISP protocol to enable centralized onboarding and management of EIDs within a network from an external controller or orchestration system. Requirements Notation |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
| | draft-ietf-pce-multipath-16.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. Returning a single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Additionally, this document updates RFC 8231 to allow encoding of multiple Segment Lists in PCEP. |
| | Multicast Lessons Learned from Decades of Deployment Experience |
| |
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. |
| | Evidence Transformations |
| |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo, concise evidence, and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation and follow CoRIM defined appraisal procedures. |
| | Static Context Header Compression (SCHC) Architecture |
| |
|
This document defines the SCHC architecture. |
| | Options representation in SCHC YANG Data Models |
| |
|
The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol. |
| | YANG Data Model for SRv6 Base |
| |
| | draft-ietf-spring-srv6-yang-base-00.txt |
| | Date: |
17/10/2025 |
| | Authors: |
Syed Raza, Jaganbabu Rajamanickam, Satoru Matsushima, Pingping Yu, Xufeng Liu |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 models accordingly. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | Testing Applications' IPv6 Support |
| |
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-Stack (IPv4+IPv6), and IPv6-only scenarios, including "true IPv6-only" scenarios. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. |
| | Workload Identity Practices |
| |
|
This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture [I-D.ietf-wimse-arch] and other protocols, such as [I-D.ietf-wimse-s2s-protocol]. |