| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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 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. |
| | 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. |
| | 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. |
| | Scalable Quality Extension for the Opus Codec (Opus HD) |
| |
|
This document updates RFC6716 to add support for a scalable quality layer. |
| | 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. |
| | 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. |
| | Storing BMP messages in MRT Format |
| |
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages. |
| | 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. |
| | 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 |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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)" |
| | 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. |
| | 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. |
| | 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]. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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]. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Single Signature KeyPackages |
| |
|
Single Signature KeyPackages improve the overhead of creating, transmitting and verifying MLS KeyPackages by removing one signature. |
| | 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. |
| | 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. |
| | 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. |
| | Extension to Connect-IP for static IP header compression |
| |
|
This document specifies an extension for IP header compression when using Connect-IP proxying. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | Join Proxy for Bootstrapping of Constrained Network Elements |
| |
|
This document extends the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a new network function, the constrained Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low- Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| | Extended Procedures for EVPN Optimized Ingress Replication |
| |
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. |
| | Delegation Revalidation by DNS Resolvers |
| |
|
This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the TTL of either the parent or child NS RRset, whichever comes first. |
| | Key Transparency Protocol |
| |
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. |
| | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP),for Enrollment over Secure Transport (EST),and for Certificate Management over CMS (CMC) |
| |
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC). |
| | Security and Privacy Considerations for Multicast Transports |
| |
|
Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. 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/squarooticus/draft-krose-multicast-security. |
| | NETCONF Extension to support Trace Context propagation |
| |
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. |
| | RESTCONF Extension to Support Trace Context Headers |
| |
|
This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. |
| | Common Interface Extension YANG Data Models |
| |
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| | OAM for Service Programming with Segment Routing |
| |
|
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. |
| | Binary Application Record Encoding (BARE) |
| |
|
The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/public-inbox@lists.sr.ht and/or the author(s). |
| | Operational Guidance for Protection mechanisms in SRv6 Networks |
| |
|
This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks. |
| | Root CA Certificate Rekeying in the Scenario of Post Quantum Migration |
| |
|
In the public key infrastructures (PKIs), root certifcation authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a one-way link certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the cerficate can be pure PQ ones or hybrid ones. |
| | Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications |
| |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes security considerations for short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | Flexible Algorithms Exclude Node |
| |
|
Flexible Algorithms provide mechanisms for creating constraint-based paths in IGP. This document introduces a routing constraint based on Node Admin-Tags, allowing for easy exclusion of device nodes from path computation. |
| | Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing |
| |
| | draft-akiyama-cmg-02.txt |
| | Date: |
19/10/2025 |
| | Authors: |
Kuon Akiyama, Ryoichi Shinkuma |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics. |
| | Requirements for Monitoring RPKI-Related Processes on Routers Using BMP |
| |
|
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers on routers, including RPKI data acquisition, RPKI-related policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize router-side monitoring on RPKI within BMP, addressing scalability and interoperability limitations in existing implementations. |
| | In-Place Bandwidth Update for MPLS RSVP-TE LSPs |
| |
|
This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB). |
| | CORECONF Rule management for SCHC |
| |
|
This document describes how CORECONF can be applied to SCHC for context and rule set management between endpoints. |
| | Reclassifying RFC6052 to Internet Standard |
| |
|
This document reclassifies IPv6 Addressing of IPv4/IPv6 Translators ([RFC6052]) to Internet Standard. |
| | SRv6 BGP Unreachable Prefix Announcement (UPA) |
| |
| | draft-krierhorn-idr-upa-01.txt |
| | Date: |
19/10/2025 |
| | Authors: |
Serge Krier, Jakub Horn, Mihai Ciurea, Jeff Tantsura, Keyur Patel |
| | Working Group: |
Individual Submissions (none) |
|
Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This mechanism, referred to as Unreachable Prefix Announcement (UPA), has been specified for IGPs. This document specifies an and equivalent BGP mechanism for multi-AS networks where BGP is used to carry summary routes. |
| | AAuth - Agentic Authorization OAuth 2.1 Extension |
| |
|
This document defines the Agent Authorization Grant, an OAuth 2.1 extension allowing a class of Internet applications - called AI Agents - to obtain access tokens in order to invoke web-based APIs on behalf of their users. In the use cases envisaged here, users interact with AI Agents through communication channels - the Public Switched Telephone Network (PSTN) or texting - which do not permit traditional OAuth grant flows. Instead, AI agents collect Personally Identifying Information (PII) through natural language conversation, and then use that collected information to obtain an access token with appropriately constrained scopes. A primary considering is ensuring that the Large Language Model (LLM) powering the AI Agent cannot, through hallucination, result in impersonation attacks. |
| | ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. |
| | EDHOC Authenticated with AKA |
| |
|
This document defines the EDHOC-AKA authentication method based on the Authentication and Key Agreement(AKA) protocol and the Ephemeral Diffie-Hellman Over COSE(EDHOC) key exchange protocol. This method is designed to provide efficient mobile communication network access authentication for scenarios with limited computing and network resources (such as Non-Terrestrial Network, NTN). EDHOC-AKA utilizes the pre-shared long-term key and employs symmetric cryptography techniques to achieve mutual authentication and key derivation. It ensures security while significantly enhancing the authentication efficiency. |
| | Site Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal hosting a site, to benefit from transparent mobility management adapting to specific connectivity and computing requirements. |
| | SayWhere Geocoding System: Human-Memorable Geographic Coordinates |
| |
|
This document specifies SayWhere, an open-source system for encoding geographic coordinates (latitude, longitude, and optional altitude) into human-memorable word phrases and decoding them back to coordinates. The system provides deterministic, reversible encoding with two-layer error detection (per-word parity and optional terminal word-phrase checksum) and supports three-dimensional positioning for multi-level structures. SayWhere introduces hierarchical variable- length phrases with true prefix relationships, enabling precision scaling from regional (1 word) to meter-level accuracy (6 words). The system uses the Bitcoin Improvement Proposal 39 (BIP-39) mnemonic wordlist for multilingual support and geohash spatial indexing for efficient location encoding. |
| | CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL) |
| |
|
This document proposes Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ). CHEQ allows humans to confirm decisions and actions proposed by AI Agents prior to those decisions being acted upon. It also allows humans to provide information required for tool invocation, without disclosing that information to the AI agent, protecting their privacy. CHEQ aims to guarantee that AI Agent hallucinations cannot result in unwanted actions by the human on whose behalf they are made. CHEQ can be integrated into protocols like the Model Context Protocol (MCP), the Agent-to-Agent (A2A) protocol, and the Normalized API for AI Agent Calling Tools (N-ACT) protocol. It makes use of a signed object which can be carried in those protocols. |
| | Framework,Use Cases and Requirements for AI Agent Protocols |
| |
|
AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. |
| | PAKE Extension for TLS Exported Authenticator |
| |
|
This document provides a mechanism that enables the use of password- authenticated key exchange (PAKE) with TLS Exported Authenticator, and that supports PAKE algorithm negotiation. |
| | Online Certificate Status Protocol (OCSP) with Certificate Validation Extension |
| |
|
This document introduces a Certificate Validation extension and a Certificate Hash extension in the Online Certificate Status Protocol (OCSP) request message and response message, respectively. OCSP is used to check the status of a certificate, and these two extensions are used to check the validity of that certificate. |
| | Multi-Provider Extensions for Agentic AI Inference APIs |
| |
|
This document specifies extensions for multi-provider distributed AI inference using the widely-adopted OpenAI Responses API as the reference interface standard. These extensions enable provider diversity, load balancing, failover, and capability negotiation in distributed inference environments while maintaining full backward compatibility with existing implementations. The extensions do not require changes to standard API usage patterns or existing client applications. By treating the OpenAI Responses API as a de facto standard interface (similar to how HTTP serves as a standard protocol), these extensions provide an optional enhancement layer for multi-provider orchestration, intelligent routing, and distributed inference capabilities. The approach preserves the familiar API interface that developers already know and use, while enabling seamless integration across multiple AI inference providers without vendor lock-in. |
| | BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects |
| |
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. |
| | YANG Data Model for Topology Filter |
| |
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. |
| | RSVP Cryptographic Authentication,Version 2 |
| |
|
This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097. |
| | RSVP Cryptographic Authentication with HMAC-SHA2 |
| |
|
This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097. |
| | VCON for MIMI Messages |
| |
|
This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (MIMI) content format. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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]. |
| | 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 |
| | 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). |
| | 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]. |