Index - Month Index of IDs
All IDs - sorted by date)
| Composite ML-DSA for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML- DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. | |||||||||||||
| Validation of Locations Around a Planned Change | ||||||||||||||
|
This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to location data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, since at a known future date, previously valid records may become invalid, and new records may become valid. This extension adds an element to the | |||||||||||||
| A Vocabulary For Expressing AI Usage Preferences | ||||||||||||||
|
This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. | |||||||||||||
| Associating AI Usage Preferences with Content in HTTP | ||||||||||||||
|
Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines how preferences can be signaled as part of the acquisition of content in HTTP. This document updates RFC 9309 to allow for the inclusion of usage preferences. | |||||||||||||
| Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication | ||||||||||||||
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. | |||||||||||||
| BFD Stability | ||||||||||||||
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. | |||||||||||||
| Export of Source Address Validation (SAV) Information in IPFIX | ||||||||||||||
|
This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to verify SAV effectiveness, audit rule correctness, and analyze source address spoofing events. | |||||||||||||
| KEM-based Authentication for EDHOC | ||||||||||||||
|
This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. The document further describes scenarios where both parties employ KEM-based authentication, as well as cases where authentication methods are combined, with one party using KEM-based authentication and the other relying on a PQC signature scheme. | |||||||||||||
| SCIM Profile for Security Event Tokens | ||||||||||||||
|
This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token Specification to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. This draft updates RFC7643 defining additional attributes for "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema and updates RFC7644 with optional new Asynchronous SCIM Request capability. | |||||||||||||
| COSE Hash Envelope | ||||||||||||||
|
This document defines new COSE header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the detached payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find original payload content. | |||||||||||||
| Amortized PQ MLS Combiner | ||||||||||||||
|
This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient amortized PQ confidentiality and authenticity that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e., an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. | |||||||||||||
| Http 528 Outbound Dependency Failed | ||||||||||||||
|
This document defines a new HTTP 5xx status code, 528 (Outbound Dependency Failed), used to indicate that a server received, parsed, and processed a request correctly, but could not complete it because a required downstream dependency malfunctioned or was in a non- transient failure state. Unlike 500 (Internal Server Error), which SHOULD be reserved for actual faults within the responding service (including improper error handling), 528 explicitly signals that the responding service operated as intended and the failure lies in a dependency. Unlike 503 (Service Unavailable), 528 does not imply a temporary condition expected to recover without intervention. | |||||||||||||
| Guidelines for Writing an IANA Considerations Section in RFCs | ||||||||||||||
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. | |||||||||||||
| Problem Statements and Requirements of Real-Virtual Agent Protocol (RVP): Communication Protocol for Embodied Intelligence in Physical- Digital Continuum | ||||||||||||||
|
The Real-Virtual Agent Protocol (RVP) enables seamless coordination between physical entities (robots, IoT devices, manufacturing systems and agents) and digital agents (AI systems, software agents, virtual twins) through unified composite identity management, physical/social/production relations graph-based coordination, and physical constraint integration. Unlike existing protocols that assume peer-to-peer digital relationships (A2A for agents, MCP for AI tools, ANP for agent networks), RVP unifies physical and digital agents communication and achieves physical data loop for online learning for embodied agents considering both hierarchical physical/social/production relations and physical world constraints. RVP is designed for immediate deployment in modern manufacturing, smart cities, autonomous mobility systems, and human-AI collaborative environments where non-peer, partially centralized relations and coordination is essential for real-world embodied intelligence networks. | |||||||||||||
| Link-Layer Types for PCAP-related Capture File Formats | ||||||||||||||
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. | |||||||||||||
| Structured Email | ||||||||||||||
|
This document specifies how a machine-readable version of the content of email messages can be added to those messages. | |||||||||||||
| Secure Reporting of SUIT Update Status | ||||||||||||||
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. | |||||||||||||
| Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events | ||||||||||||||
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, RFC 8106, and RFC 9096. | |||||||||||||
| Carrying Network Resource (NR) related Information in IPv6 Extension Header | ||||||||||||||
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (which is called NRP Selector) need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. | |||||||||||||
| IPv6 Node Requirements | ||||||||||||||
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. | |||||||||||||
| YANG Data Model for IPv6 Neighbor Discovery | ||||||||||||||
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. | |||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. | |||||||||||||
| Protecting EST Payloads with OSCORE | ||||||||||||||
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. | |||||||||||||
| Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. | |||||||||||||
| CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. | |||||||||||||
| A Voucher Artifact for Bootstrapping Protocols | ||||||||||||||
|
This document defines a strategy to securely assign a Pledge to an owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, includes a number of desired extensions into the YANG. The voucher request defined in RFC8995 is also now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995. | |||||||||||||
| 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. | |||||||||||||
| Automatic Peering for SIP Trunks | ||||||||||||||
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. | |||||||||||||
| Semantic Definition Format (SDF) Extension for Non-Affordance Information | ||||||||||||||
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. | |||||||||||||
| EVPN-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 | ||||||||||||||
|
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 | ||||||||||||||
|
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 Framework for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes. | |||||||||||||
| CATS Metrics Definition | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from the computing domain used for CATS. | |||||||||||||
| A YANG data model to manage configurable DWDM optical interfaces | ||||||||||||||
|
This memo defines a YANG model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The YANG model defined in this memo can be used for Optical Parameters monitoring and/or configuration of DWDM interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | |||||||||||||
| A YANG Data Model for WDM Tunnels | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| BBR Congestion Control | ||||||||||||||
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. | |||||||||||||
| Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition | ||||||||||||||
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate, and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. | |||||||||||||
| Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. | |||||||||||||
| Concrete Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. | |||||||||||||
| Interactive Sigma Proofs | ||||||||||||||
|
A Sigma Protocol is an interactive zero-knowledge proof of knowledge that allows a prover to convince a verifier of the validity of a statement. It satisfies the properties of completeness, soundness, and zero-knowledge, as described in Section 3. This document describes Sigma Protocols for proving knowledge of pre- images of linear maps in prime-order elliptic curve groups. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. | |||||||||||||
| Fiat-Shamir Transformation | ||||||||||||||
|
This document describes how to construct a non-interactive proof via the Fiat–Shamir transformation, using a generic procedure that compiles an interactive proof into a non-interactive one by relying on a stateful hash object that provides a duplex sponge interface. The duplex sponge interface requires two methods: absorb and squeeze, which respectively read and write elements of a specified base type. The absorb operation incrementally updates the sponge's internal hash state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with various hash functions based on permutation or compression functions. This specification also defines codecs to securely map elements from the prover into the duplex sponge domain, and from the duplex sponge domain into verifier messages. | |||||||||||||
| Constrained Resource Identifiers | ||||||||||||||
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry as well as a note on how that registry cooperates with the "CRI Scheme Numbers for Certain Unregistered Scheme Names" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision -27 is a fixup to revision -26, which was missing // the fixes for Éric Vyncke's COMMENTs. This is now intended to be // ready for document approval. | |||||||||||||
| Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. | |||||||||||||
| Key Update for OSCORE (KUDOS) | ||||||||||||||
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. | |||||||||||||
| Constrained Application Protocol (CoAP) Performance Measurement Option | ||||||||||||||
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. | |||||||||||||
| Identifier Update for OSCORE | ||||||||||||||
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. | |||||||||||||
| URI-Path abbreviation in CoAP | ||||||||||||||
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus registering (relatively verbose) well-known URI paths. This document introduces an option that allows expressing well-known paths in as little as two bytes. | |||||||||||||
| Using Proxies for Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. The present version -00 refers to version -12 of draft-ietf-core- observe-multicast-notifications, which includes content about proxies that is also included in the present document. Such content will be removed from draft-ietf-core-observe-multicast-notifications in its next revision. | |||||||||||||
| An Architecture for DNS-Bound Client and Sender Identities | ||||||||||||||
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. | |||||||||||||
| Extensible Delegation for DNS | ||||||||||||||
|
This document proposes a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGI records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information. | |||||||||||||
| DKIM2 Header Definitions | ||||||||||||||
|
This document describes the email header fields defined for DKIM2, and how they work togther to provide the required properties. This is an early draft, a work in progress. | |||||||||||||
| Mobile User Plane Architecture for Distributed Mobility Management | ||||||||||||||
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case (SRv6 MUP) due to the DMM requirement, and is suitable for mobile services which require a large IP address space. | |||||||||||||
| Operational Recommendations for DS Automation | ||||||||||||||
|
Enabling support for automatic acceptance of DS parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parent operator, often a registry or registrar, to make a number of technical decisions. This document describes recommendations for new deployments of such DS automation. | |||||||||||||
| Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option | ||||||||||||||
|
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 | ||||||||||||||
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). | |||||||||||||
| Happy Eyeballs Version 3: Better Connectivity Using Concurrency | ||||||||||||||
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. | |||||||||||||
| Resumable Uploads for HTTP | ||||||||||||||
|
HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was received prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. | |||||||||||||
| IAB Processes for Management of IETF Liaison Relationships | ||||||||||||||
|
This document discusses the procedures used by the IAB to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers, and the expectations of the IAB in establishing liaison relationships. | |||||||||||||
| Pacing in Transport Protocols | ||||||||||||||
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. | |||||||||||||
| BGP Link-State Extensions for BGP-only Networks | ||||||||||||||
|
BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address- family and the procedures for advertisement of topology information in a BGP-only network. | |||||||||||||
| BGP Next-next Hop Nodes | ||||||||||||||
|
BGP speakers learn their next hop addresses for NLRI in RFC 4271 in the NEXT_HOP field and in RFC 4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. | |||||||||||||
| Responsiveness under Working Conditions | ||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. | |||||||||||||
| Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC | ||||||||||||||
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. | |||||||||||||
| A YANG Network Data Model for Inventory Topology Mapping | ||||||||||||||
|
This document defines a YANG data model to map the network inventory data with the topology data to form a base underlay network. The data model facilitates the correlation between the layer (e.g., Layer 2 or Layer 3) topology information and the inventory data of the underlay network for better service provisioning, network maintenance operations, and other assessment scenarios. | |||||||||||||
| A YANG Network Data Model of Network Inventory Software Extensions | ||||||||||||||
|
This document extends the base Network Inventory YANG model to support non-physical network elements (NEs), such as controllers, virtual routers, and virtual firewalls, as well as software components like platform operating systems and software modules. In addition to the software revisions and patches already defined in the base model, this extension introduces software status and time stamp information. | |||||||||||||
| A YANG Module for Entitlement Inventory | ||||||||||||||
|
This document proposes a YANG module for incorporating entitlements in a network inventory, encompassing both virtual and physical network elements. Entitlements define the rights for their holder to use specific capabilities in a network element(s). The model is rooted by the concept of the capabilities offered by an element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. | |||||||||||||
| JSON Proof Token and CBOR Proof Token | ||||||||||||||
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. | |||||||||||||
| JSON Web Proof | ||||||||||||||
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a Presentation Header to prevent replay. | |||||||||||||
| JSON Proof Algorithms | ||||||||||||||
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. | |||||||||||||
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | ||||||||||||||
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. | |||||||||||||
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, In order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. | |||||||||||||
| EDHOC Authenticated with Pre-Shared Keys (PSK) | ||||||||||||||
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. | |||||||||||||
| Remote attestation over EDHOC | ||||||||||||||
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. | |||||||||||||
| Certificate Management over CMS (CMC) | ||||||||||||||
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: | |||||||||||||
| Certificate Management over CMS (CMC): Transport Protocols | ||||||||||||||
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFC 5273 and RFC 6402. | |||||||||||||
| Certificate Management Messages over CMS (CMC): Compliance Requirements | ||||||||||||||
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFC 5274 and RFC 6402. | |||||||||||||
| LISP L2/L3 EID Mobility Using a Unified Control Plane | ||||||||||||||
|
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. | |||||||||||||
| IS-IS Distributed Flooding Reduction | ||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. | |||||||||||||
| 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. | |||||||||||||
| Registration of further IMAP/JMAP keywords and mailbox name attributes | ||||||||||||||
|
This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It defines the intended use of these keywords and mailbox name attributes. This document registers all of these with IANA to avoid name collisions. | |||||||||||||
| Automatic Configuration of Email,Calendar,and Contact Server Settings | ||||||||||||||
|
This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures. | |||||||||||||
| DLEP Radio Quality Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. | |||||||||||||
| DLEP Radio Band Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide information about frequency bands used by the radio. | |||||||||||||
| DLEP Radio Channel Utilization Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. | |||||||||||||
| Non-source-routed Multicast in SR Networks | ||||||||||||||
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. | |||||||||||||
| An Architecture for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. | |||||||||||||
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS | ||||||||||||||
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. | |||||||||||||
| Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol | ||||||||||||||
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. | |||||||||||||
| Scalable Quality Extension for the Opus Codec (Opus HD) | ||||||||||||||
|
This document updates RFC6716 to add support for a scalable quality layer. | |||||||||||||
| Network Overlay Impacts to Streaming Video | ||||||||||||||
|
This document examines the operational impacts on streaming video applications resulting from network policy changes introduced by network overlays. Such overlays may alter IP address assignment, transport protocols, routing behavior, or DNS resolution. These changes can, in turn, affect critical aspects of content delivery, including latency, CDN cache selection, delivery path optimization, traffic classification, and content access controls. | |||||||||||||
| Media over QUIC Transport | ||||||||||||||
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. | |||||||||||||
| Privacy Pass Authentication for Media over QUIC (MoQ) | ||||||||||||||
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. | |||||||||||||
| YANG Data Model for MPLS mLDP | ||||||||||||||
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| List Pagination for YANG-driven Protocols | ||||||||||||||
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. | |||||||||||||
| NETCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the | |||||||||||||
| RESTCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. | |||||||||||||
| Extensible YANG Model for YANG-Push Notifications | ||||||||||||||
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the changed data was observed. | |||||||||||||
| YANG Schema Comparison | ||||||||||||||
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm. | |||||||||||||
| YANG module file name convention | ||||||||||||||
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and draft-ietf-netmod- rfc8407bis. | |||||||||||||
| An Architecture for YANG-Push to Message Broker Integration | ||||||||||||||
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. | |||||||||||||
| Extensible YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. | |||||||||||||
| Considerations of network/system for AI services | ||||||||||||||
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, it has changed from running only on very high-performance servers to running on commodity servers, with affordable, small-scale hardware, including microcontrollers, low-performance CPUs, and AI chipsets. This document outlines how to configure the network and system for an AI inference service, providing AI services in a distributed manner. It also outlines the factors to consider when a client connects to a cloud server and an edge device to requests an AI service. It describes some use cases for deploying network-based AI services, such as self-driving vehicles and network digital twins. | |||||||||||||
| CoAP: Non-traditional response forms | ||||||||||||||
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. The design spaces for the new CoAP Options proposed to represent these responses are now sufficiently understood that they can be developed to standards-track specifications, either in this document or by transferring the specification for an Option to a document that that Option closely works with. | |||||||||||||
| Storing BMP messages in MRT Format | ||||||||||||||
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages. | |||||||||||||
| CoAP over GATT (Bluetooth Low Energy Generic Attributes) | ||||||||||||||
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. | |||||||||||||
| PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE | ||||||||||||||
|
This draft specify extensions to PCEP protocol when a PCE-based controller is responsible for allocates the BIER-TE information(BIER subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc), then PCC generate a "Bit Index Forwarding Table"(BIFT). | |||||||||||||
| DC aware TE topology model | ||||||||||||||
|
This document proposes the extension of the TE topology model for including information related to data center resource capabilities. For that purpose, it defines a YANG module to augment TE topologies with awareness of data-center computing resources. Although the model is designed to be compatible with TE aware topologies, it can also be applied to non-TE networks. | |||||||||||||
| Signaling Composite Candidate Path of SR Policy using BGP-LS | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. | |||||||||||||
| 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. | |||||||||||||
| EVPN multi-homing support for L3 services | ||||||||||||||
|
This document describes the use of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to improve network availability and load balancing for Layer 3 (L3) services with EVPN. In this approach, all synchronized routes ensure the correct L3 state within Virtual Routing and Forwarding (VRF) instances. Unlike traditional deployments, these L3 services operate entirely at Layer 3 and do not require Layer 2 constructs such as Ethernet Virtual Instances (EVIs), MAC-VRFs, Bridge Domains (BDs), or Integrated Routing and Bridging (IRB) interfaces. | |||||||||||||
| 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. | |||||||||||||
| Multi-Topology in PIM | ||||||||||||||
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. | |||||||||||||
| 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. | |||||||||||||
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets | ||||||||||||||
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. | |||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | ||||||||||||||
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. | |||||||||||||
| EVPN Multicast Forwarding for EVPN to EVPN Gateways | ||||||||||||||
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. | |||||||||||||
| Identity for E2E-Secure Communications | ||||||||||||||
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. | |||||||||||||
| Source IPv6 Address Programmability | ||||||||||||||
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information | |||||||||||||
| EVPN Inter-Domain Option-B Solution | ||||||||||||||
|
An EVPN Inter-Domain interconnect solution is required when two or more sites of the same Ethernet Virtual Private Network (EVPN) are connected to different IGP domains or Autonomous Systems (AS) and need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for this type of EVPN connectivity. While several documents address specific aspects of this interconnect approach, none provide a comprehensive overview of how Inter-Domain Option-B connectivity affects EVPN procedures. This document examines the behavior of EVPN procedures in an Inter-Domain Option-B network and proposes solutions to the identified issues. | |||||||||||||
| Realization of Composite IETF Network Slices | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. | |||||||||||||
| Aircraft to Anything AdHoc Broadcasts and Session | ||||||||||||||
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. | |||||||||||||
| Green Challenges in Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. | |||||||||||||
| SCION Control Plane | ||||||||||||||
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks | ||||||||||||||
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. | |||||||||||||
| Multiple Algorithm Rules in DNSSEC | ||||||||||||||
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035 and 6840. | |||||||||||||
| Validity of SR Policy Candidate Path | ||||||||||||||
|
An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active (i.e., installed in forwarding and usable for steering of traffic). Each CP in turn may have one or more SID-List of which one or more may be active; when multiple SID-List are active then traffic is load balanced over them. However, a candidate path is valid when at least one SID-List is active. This candidate path validity criterion cannot meet the needs of some scenarios. This document defines the new candidate path validity criterion. | |||||||||||||
| SCION Data Plane | ||||||||||||||
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION Data Plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| Automating DNS Delegation Management via DDNS | ||||||||||||||
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| Path Computation Based on Precision Availability Metrics | ||||||||||||||
|
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. | |||||||||||||
| MLS Virtual Clients | ||||||||||||||
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. | |||||||||||||
| 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 | ||||||||||||||
|
This document specifies the schemas and models required to realize the data formats and interfaces for Intent-Based Networking (IBN). They are needed to enable the composition of services to build a translation engine for IBN-based network management. This intent translation engine (called an intent translator) is an essential function for network intents to be enforced into a target network for the configuration and management of the network and its security. | |||||||||||||
| Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms | ||||||||||||||
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. | |||||||||||||
| Advanced Professional Video | ||||||||||||||
|
This document describes the bitstream format of Advanced Professional Video (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production. | |||||||||||||
| A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology | ||||||||||||||
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Intermediate System to Intermediate System (IS-IS). This document augments the 'ietf-network' and 'ietf-network-topology' data models by adding IS- IS concepts and explains how the data model can be used to represent the IS-IS topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| Self-Clocked Rate Adaptation for Multimedia | ||||||||||||||
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. This specification obsoletes RFC 8298. | |||||||||||||
| End-to-End Secure Objects for Media over QUIC Transport | ||||||||||||||
|
This document describes an end-to-end authenticated encryption scheme for application objects intended to be delivered over Media over QUIC Transport (MOQT). We reuse the SFrame scheme for authenticated encryption of media objects, while suppressing data that would be redundant between SFrame and MOQT, for an efficient on-the-wire representation. | |||||||||||||
| 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS | ||||||||||||||
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. | |||||||||||||
| Common BMP Route-Monitoring Messages for Routes Unchanged by Policy | ||||||||||||||
|
A route unmodified by the inbound policy on a monitored router is included both in Pre-Policy Adj-RIB-In as well as Post-Policy Adj- RIB-In Route-Monitoring messages when both the Pre-Policy and Post- Policy Route-Monitoring modes are enabled. Similarly, a route unmodified by the outbound policy is included in Pre-Policy Adj-RIB- Out as well as Post-Policy Adj-RIB-Out Route-Monitoring messages. This document defines a method to avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out. | |||||||||||||
| Multiple Hop Unaffiliate BFD | ||||||||||||||
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. | |||||||||||||
| Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces | ||||||||||||||
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. | |||||||||||||
| Automatic Extended Route Optimization (AERO) | ||||||||||||||
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI use IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. AERO is a widely-applicable service especially well-suited for air/land/sea/space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. | |||||||||||||
| A YANG Data Model for Open Shortest Path First (OSPF) Topology | ||||||||||||||
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| BGP Extensions of SR Policy for Composite Candidate Path | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. | |||||||||||||
| Advertising Router Information | ||||||||||||||
|
This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes. | |||||||||||||
| Logging over Media over QUIC Transport | ||||||||||||||
|
Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. | |||||||||||||
| Metrics over MOQT | ||||||||||||||
|
This document specifies how to send metrics type information over the Media Over QUIC Transport (MOQT). Many systems produce significant volumes of metrics which either are not all needed at the same time for consumption by collection/ aggregation endpoints or may also compete for bandwidth with the primary application, thus exacerbating congestion conditions especially in low-bandwidth networks. Delivering these over architectures enabled by publish/subscribe transport like Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport], allows metrics data to be prioritized within the congestion context of the primary application as well as enabling local nodes to cache the metric value to be later retrieved via new subscriptions. | |||||||||||||
| Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation | ||||||||||||||
|
This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations. | |||||||||||||
| 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. | |||||||||||||
| Mobile Traffic Steering | ||||||||||||||
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. | |||||||||||||
| 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. | |||||||||||||
| MASQUE extension for signaling throughput advice | ||||||||||||||
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. | |||||||||||||
| LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various Label Switched Path (LSP) identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. | |||||||||||||
| Secure UAS Stateless Network RID | ||||||||||||||
|
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state. | |||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| MoQ Media Interop | ||||||||||||||
|
This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT], using LOC[loc] packaging. | |||||||||||||
| SAVI in a LISP network | ||||||||||||||
|
This document specifies the procedures for Source Address Validation of LISP Endpoint Identifiers (EID). The implementation of these mechanisms provides endpoint detection, on-boarding and roaming support in LISP networks, while protecting against IP address spoofing. | |||||||||||||
| Traceability Claims | ||||||||||||||
|
This document defines claims to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. These claims are registered for use in both CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs). | |||||||||||||
| BMP Snapshots | ||||||||||||||
|
BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The issue is that the necessary information to produce a complete view and enabling correct processing of all messages in the stream, is only sent out at the beginning of the BMP session. This document introduces the concept of BMP Snapshots, enabling BMP stations to synchronize mid-stream, and, providing the basis for self-contained, time-binned archiving of BMP data. | |||||||||||||
| Advertise SRv6 Locator Information by IPv6 Neighbor Discovery | ||||||||||||||
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. | |||||||||||||
| Best Practices for CMS SignedData with Regards to Signed Attributes | ||||||||||||||
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists best practices and mitigations for such a vulnerability. | |||||||||||||
| 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. | |||||||||||||
| Post-Quantum Guidance for current deployments of IETF protocols. | ||||||||||||||
|
We provide guidance on the use of post-quantum algorithms for those deploying applications using IETF protocols. | |||||||||||||
| WIMSE Credential Exchange | ||||||||||||||
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. | |||||||||||||
| Stateless Hash-Based Signatures for Secure Shell (SSH) | ||||||||||||||
|
This document describes the use of Sphincs+/SLH-DSA digital signatures, standalone and as a hybrid with Ed25519/Ed448, in the Secure Shell (SSH) protocol. | |||||||||||||
| Privacy Pass Reverse Flow | ||||||||||||||
|
This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue new tokens in response to a request in which a token is redeemed. | |||||||||||||
| Dynamic Overlay Load Balancing | ||||||||||||||
|
This document specifies a mechanism for an overlay service ingress PE to dynamically load-balance traffic to Multi-Homing PEs based on near real-time access link information advertised by those PEs. | |||||||||||||
| Lightweight Authentication for Encapsulation Header | ||||||||||||||
|
This document specifies a lightweight authentication mechanism (KeyID, anti-replay, algorithms, truncation, and keying) intended to be reused by multiple protocol profiles. Concrete profiles define where the authentication data is carried and the exact coverage rules for header fields. | |||||||||||||
| Messaging Layer Security Credentials using Selective Disclosure JSON and CBOR Web Tokens | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. | |||||||||||||
| Framework for High Performance Wide Area Network (HP-WAN) | ||||||||||||||
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time and low latency of High Performance Wide Area Networks (HP-WAN). It focuses on key congestion control functions to facilitate host-to-network collaboration and perform rate negotiation, such as QoS policy, admission control, and traffic scheduling. | |||||||||||||
| IPv6 Network Deployment Monitoring and Analysis | ||||||||||||||
|
This document identifies key operational challenges in large-scale IPv6 deployment and proposes a set of proven, integrated monitoring and analysis frameworks to address them. By establishing a standardized architecture and a comprehensive evaluation index system, it enables end-to-end visibility across cloud, network, edge, and end systems. This document provides complete operational guidance from data collection and cross-domain correlation to intelligent analysis and bottleneck identification, offering executable solutions for operators to accelerate IPv6 deployment. The described best practices have been validated in the live networks of major operators, achieving significant improvements in IPv6 traffic. | |||||||||||||
| Large Model based Agents for Network Operation and Maintenance | ||||||||||||||
|
Current advancements in AI technologies, particularly large models, have demonstrated immense potential in content generation, reasoning, analysis and so on, providing robust technical support for network automation and self-intelligence. However, in practical network operations, challenges such as system isolation and fragmented data lead to extensive manual, repetitive, and inefficient tasks, the improvement of intelligence level is very necessary. This document identifies typical scenarios requiring enhanced intelligence, and explains how AI Agents and large model technologies can empower networks to address operational pain points, reduce manual efforts, and explore impacts on network data, system architectures, and interfaces correspondingly. It further explores and summarizes standardization efforts in implementation. | |||||||||||||
| Remote Attestation with Multiple Verifiers | ||||||||||||||
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. | |||||||||||||
| YANG Datastore Telemetry (YANG Push Lite) | ||||||||||||||
|
YANG Push Lite is a YANG datastore telemetry solution, as an alternative specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. | |||||||||||||
| PCEP extensions for energy consumption | ||||||||||||||
|
[draft-liu-spring-sr-energy-consumption-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document further details the process of using the PCEP protocol for energy consumption based path requests. The Path Computation Element Communication Protocol (PCEP) provides mechanisms that enable Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs). This document describes the extension to PCEP for conveying link energy consumption and node energy consumption, allowing path computation based on these energy consumption information. | |||||||||||||
| RADIUS over QUIC | ||||||||||||||
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. | |||||||||||||
| MoQ qlog event definitions | ||||||||||||||
|
This document defines a qlog event schema containing concrete events for MoQ. | |||||||||||||
| ACP free "Automation Network Infrastructure" for simple in-network automation (aNI) | ||||||||||||||
|
This document describes how to to build the software infrastructure for distributed automation agents using a lightweight variation of the "Autonomic Networking Infrastructure" (ANI), by using the existing ANI domain keying material (certificates and trust anchors) as well as the protocols GRASP and BRSKI protocols, but eliminating the expensive to implement "Autonomic Control Plane" (ACP) and adding proxying "Autonomic Software Agents" (ASA) instead. The resulting infrastructure is called "automation Network Infrastructure" and can be implemented solely as application level software components on routers, switches or co-located managemenet devices, avoiding the need to change any router or switches forwarding or control-plane protocols. The aNI achieves mosts of the benefits of the ANI but foregoes the ability to easily make pre-existing, insecure control-plane protocols secure or provide all the same protection against operator or SDN controller misconfigurations that the ACP provides. | |||||||||||||
| Secure Asset Transfer Protocol (SATP) Implementation Guide | ||||||||||||||
|
This memo provides implementation guidelines for the Secure Asset Transfer Protocol (SATP). It is intended for developers of SATP gateway and digital asset networks they represent. This document also clarifies the core SATP processing workflow and offers recommendations to ensure interoperable implementations, particularly in environments where multiple gateways may represent the same network. | |||||||||||||
| Proposal for Updates to Guidance on Packet Reordering | ||||||||||||||
|
Several link technology standards mandate that equipment guarantee in-order delivery of layer 2 frames, apparently due to a belief that this is required by higher layer protocols. To meet this requirement they implement a "resequencing" operation to restore the original packet order. This can introduce delays that result in net degradation of performance. Modern TCP and QUIC implementations support features that significantly improve their tolerance to out- of-order delivery. This draft is intended to provide new information for layer 2 technology standards regarding the need to assure in- order delivery to support IETF protocols. | |||||||||||||
| CCNx Content Versioning | ||||||||||||||
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content sharing the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. | |||||||||||||
| Personal Data Portability Archive | ||||||||||||||
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. | |||||||||||||
| 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. | |||||||||||||
| SSH Certificate Format | ||||||||||||||
|
This document presents a simple certificate format that may be used in the context of the Secure Shell (SSH) protocol for user and host authentication. | |||||||||||||
| Guidelines for Considering Operations and Management in IETF Specifications | ||||||||||||||
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when defining New Protocols or Protocol Extensions. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream. | |||||||||||||
| HTTP Message Signatures Directory | ||||||||||||||
|
This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as new HTTP Method Context to allow for in-band key discovery. | |||||||||||||
| HTTP Message Signatures for automated traffic Architecture | ||||||||||||||
|
This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. | |||||||||||||
| LDP Extensions for Flex-Algo | ||||||||||||||
|
This document specifies extensions to LDP to support the use Flex- Algo, enabling Label Switched Paths (LSPs) to follow a specific Flex-Algo. | |||||||||||||
| Framework for Energy Efficiency Management | ||||||||||||||
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. | |||||||||||||
| Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0 | ||||||||||||||
|
The Automatic Certificate Management Environment (ACME) protocol allows server operators to obtain TLS certificates for their websites, based on a demonstration of control over the website's domain via a fully-automated challenge/response protocol. OpenID Federation 1.0 defines how to build a trust infrastructure using a trusted third-party model. It uses a trust evaluation mechanism to attest to the possession of private keys, protocol specific metadata and miscellaneous administrative and technical information related to a specific entity. This document defines how X.509 certificates associated with a given OpenID Federation Entity can be issued by an X.509 Certification Authority through the ACME protocol to the organizations which are part of a federation built on top of OpenID Federation 1.0. | |||||||||||||
| Authoritative DNS Transport Signaling | ||||||||||||||
|
This document proposes a mechanism for authoritative DNS servers to signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)). This signaling may either be provided within the Additional section of authoritative DNS responses or be the result of direct DNS queries. The former, "opportunistic mode" is hint-based and aims to enable resolvers to discover alternative transports efficiently and then opportunistically upgrade connections to the authoritative, thereby improving privacy, security, and performance for subsequent interactions. The mechanism is designed to not require any protocol change or additional queries. It is safe, backward-compatible, and effective even when DNSSEC validation of the hint is not possible or desired. In certain circumstances and with additional overhead it is also possible to use direct queries to securely obtain authentication information for the authoritative that can then be used to authenticate an encrypted connection. It is also possible to establish a "validated mode" where the communication between the resolver and the authoritative server is provably both secure and authentic. Validated mode may not always be possible, depending on whether the resolver is able to DNSSEC validate the signal or not. When Validated mode is possible it does provide a stronger and more trustworthy connection. This document proposes an improvement to the opportunistic (but blind) testing of alternative transports suggested in RFC9539 by providing a mechanism by which a responding authoritative server may signal what alternative transports it supports. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-transport-signaling (https://github.com/johanix/draft-johani-dnsop-transport-signaling). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| Multipath Traffic Engineering for Segment Routing | ||||||||||||||
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. | |||||||||||||
| Further considerations on AI Agent Authentication and Authorization Based on OAuth Extension | ||||||||||||||
|
Agent Communication Network(ACN) is becoming a promising and fundamental infrastructure for most vertical industries. To construct and build a scalable and trustable ACN, authentication and authorization of AI agents are critical requirements. This document extends the model of OAuth and proposes new workflows for AI agent authentication and authorization. | |||||||||||||
| Network Digital Twin based Architecture for AI driven Network Operations | ||||||||||||||
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Integrating a Network Digital Twin into network management together with AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Network Digital Twin and AI which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together. It provides a cookbook of existing technologies to satisfy the architecture and realize intent-based networking to meet the needs of the network service. | |||||||||||||
| Post-Quantum Algorithms guidance | ||||||||||||||
|
This document provides general information (such as parameter sizes, security assumptions, and targeted security models) on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. The cryptographic schemes described in this document are among those recommended by major security agencies and/or standardization bodies, and are believed to be secure against Cryptographically Relevant Quantum Computer (CRQC). The goal of this document is to offer a high-level overview of these schemes and their distinguishing features, to help implementers, protocol designers, standards developers, and policymakers in understanding and selecting appropriate post-quantum cryptographic primitives for use in protocols and systems. By aggregating and presenting this information in a unified format, this document aims to facilitate informed decision-making and interoperability during the migration to post-quantum cryptography, and to encourage consistent practices when evaluating and deploying Post-Quantum Cryptography (PQC) schemes in cryptographic protocols. | |||||||||||||
| RTP Payload Format for Avatar Representation Format (ARF) Animations | ||||||||||||||
|
This memo outlines RTP payload formats for the animation stream format as defined in the ISO/IEC 23090-39 specification (MPEG-I Avatar Representation Format). An animation stream format is composed of Avatar Animation Units (AAU) including an AAU header and zero or more AAU packets. The RTP payload header format allows for packetization of an AAU unit in an RTP packet payload as well as fragmentation of an AAU into multiple RTP packets. | |||||||||||||
| Usecase and requirement of deploying PFC and fine-grained flow control | ||||||||||||||
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. | |||||||||||||
| Validating anydata in YANG Library context | ||||||||||||||
|
This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. | |||||||||||||
| 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. | |||||||||||||
| SRv6 Policy SID List Optimization | ||||||||||||||
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes. In some use cases, an SRv6 Policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies procedures to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. | |||||||||||||
| FANTEL Use Cases and Requirements in Wide Area Network | ||||||||||||||
|
This document introduces the main scenarios related to AI services in WAN, as well as their requirements for FANTEL (FAst Notification for Traffic Engineering and Load balancing) in these scenarios. Traditional network management mechanisms are often constrained by slow feedback and high overhead, limiting their ability to react quickly to sudden link failures, congestion, or load imbalances. Therefore, these AI services need FANTEL to provide real-time and proactive notifications for traffic engineering and load balancing, meeting the requirements of ultra-high throughput and lossless data transmission. | |||||||||||||
| Domain Name Specification for DKIM2 | ||||||||||||||
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. | |||||||||||||
| Multicast usage in LLM MoE | ||||||||||||||
|
Large Language Models (LLMs) have been widely used in recent years. The Mixture of Experts (MoE) architecture is one of the features of LLMs that enables efficient inference and cost-effective training. With the MoE architecture, there are potential multicast use cases such as tokens dispatching. This draft attempts to analyze these use cases. | |||||||||||||
| Stateless Encryption Scheme of Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This draft first introduces several use cases for stateless encryption, analyzes and compares some existing stateless encryption schemes in the industry, and then attempts to propose a general and flexible stateless encryption scheme based on the summarized requirements. | |||||||||||||
| Quantum-Resistant Cipher Suites for EDHOC | ||||||||||||||
|
The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. | |||||||||||||
| An Intent Translation Framework for Internet of Things | ||||||||||||||
|
The evolution of 6G networks and the expansion of Internet of Things (IoT) environments introduce new challenges in managing diverse networked resources. Intent-based management frameworks enable operators to express desired network outcomes using high-level intents, often articulated in natural language. However, converting these expressions into machine-executable policy configurations remains an open challenge. This document defines an intent translation framework designed to bridge the gap between user-issued intents and structured policy representations for 6G enabled IoT systems. The framework accepts natural language intent as input and produces a policy document in a structured format, such as YAML, that aligns with the intent model defined in 3GPP in [TS-28.312]. The framework consists of modular components responsible for processing input, aligning user intent with domain knowledge, evaluating semantic confidence, and generating standardized output. This modularity supports transparency, interoperability, and automated policy enforcement in next-generation network infrastructures. | |||||||||||||
| Integration of Remote Attestation with Key Negotiation and Key Distribution mechanisms | ||||||||||||||
|
This draft proposes a lightweight security enhancement scheme based on integration of remote attestation with key negotiation and key distribution. Correctly integrating the main steps of end-to-end key negotiation into the remote attestation process may provide more security and flexibility. | |||||||||||||
| DNS data representation for use in RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document proposes a unified, extensible JSON representation for DNS resource records for use in the RESTful Provisioning Protocol (RPP). The aim is to create a single, consistent structure for provisioning all DNS-related data - including delegation, DNSSEC, and other record types - that directly mirrors the DNS data model and being mappable to existing EPP model of requests and responses same time. This approach simplifies the adoption of both current and future DNS features by aligning the provisioning format with the target system, thereby streamlining the management of domain names and related objects within RPP. | |||||||||||||
| Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option | ||||||||||||||
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. | |||||||||||||
| A YANG Data Model for SIMAP | ||||||||||||||
|
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 | ||||||||||||||
|
Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols. | |||||||||||||
| Consideration for IP-Based Satellite Routing Protocol | ||||||||||||||
|
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations. | |||||||||||||
| RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. | |||||||||||||
| P2P Chat with MoQ | ||||||||||||||
|
This protocol is designed for small groups of users sending relatively small messages. It is optimized for the assumption that a node will come online and collect all messages at least once every 15 days and that some nodes that act as mirrors will be online most of the time but may come and go over long periods of time. | |||||||||||||
| A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. | |||||||||||||
| Mapping Open Cybersecurity Schema Framework Events to Media over QUIC Transport | ||||||||||||||
|
This document defines a mapping specification for representing Open Cybersecurity Schema Framework (OCSF) events, categories, and profiles using Media over QUIC Transport (MOQT) tracks. The mapping leverages MOQT's hierarchical data model and publish/subscribe architecture to enable real-time, in-network cached, scalable distribution of cybersecurity event data across networks while maintaining OCSF's structured taxonomy and semantic relationships. | |||||||||||||
| Applicability & Manageability consideration for SCONE | ||||||||||||||
|
This document describes the applicability and manageability considerations for providing throughput guidance to application endpoints in telecommunications service provider networks supporting the Standard Communication with Network Elements (SCONE) protocol. | |||||||||||||
| Test Battery for Opus ML Codec Extensions | ||||||||||||||
|
This document proposes methodology and data for evaluation of machine learning (ML) codec extensions, such as the deep audio redundancy (DRED), within the Opus codec (RFC6716). | |||||||||||||
| Network infrastructure Hiding Protocol | ||||||||||||||
|
The Network infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to implement Zero Trust principles by rendering protected network resources invisible to unauthorized entities. By requiring authentication before connection and operating at OSI layers 5 , NHP conceals IP addresses, ports, and domains from exposure to reconnaissance and automated exploitation, effectively reducing the attack surface. This draft defines the architecture, message format, and workflow of the NHP protocol, outlines its security objectives, and provides guidance for integration into modern network infrastructures and Zero Trust deployments. title: "Network-Infrastructure Hiding Protocol (NHP)" abbrev: "NHP" docname: draft-opennhp-ace-nhp-01 category: informational stream: independent submissiontype: independent number: 00 date: 2025-10-19 v: 1 area: "Security" workgroup: "secdp" keyword: * zero trust * session layer * network obfuscation venue: group: "saag" type: "Independent Submission" mail: "saag@ietf.org (mailto:saag@ietf.org)" arch: "https://mailarchive.ietf.org/arch/browse/secdp/ (https://mailarchive.ietf.org/arch/browse/secdp/)" github: "OpenNHP/ietf-rfc-nhp" latest: "https://OpenNHP.github.io/ietf- rfc-nhp/draft-opennhp-ace-nhp.html (https://OpenNHP.github.io/ ietf-rfc-nhp/draft-opennhp-ace-nhp.html)" | |||||||||||||
| Taxonomy of Composite Attesters | ||||||||||||||
|
This document further refines different kinds of RFC 9334 Composite Attesters. | |||||||||||||
| Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys | ||||||||||||||
|
As described in RFC5280, key usages are specified in X.509 certificates using the certificate extensions "Key Usage" and "Extended Key Usage". This document defines an Extended Key Usage (EKU) relating to keys that are dedicated to the purpose of signing attestation evidence as introduced in RFC9334. | |||||||||||||
| DomainKeys Identified Mail Signatures v2 (DKIM2) | ||||||||||||||
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by applying a cryptographic signature to the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient further signatures will be added to provide a validatable "chain". This permits validators to identify when messages have been unexpectedly "replayed" and can ensure that delivery status notifications are only sent to entities that were involved in the transmission of a message. | |||||||||||||
| Registry and Signature Agent card for Web bot auth | ||||||||||||||
|
This document describes a JSON based format for clients using [DIRECTORY] to advertise information about themselves. This document describes a JSON-based "Signature Agent Card" format for signature agent using [DIRECTORY] to advertise metadata about themselve. This includes identity, purpose, rate expectations, and cryptographic keys. It also establishes an IANA registry for Signature Agent Card parameters, enabling extensible and interoperable discovery of agent information. | |||||||||||||
| YANG Message Keys for Message Broker Integration | ||||||||||||||
|
This document specifies a mechanism to define a unique message key for a YANG to message broker integration and a topic addressing scheme based on YANG-Push subscription type and a YANG index defined in this document. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG node, identifier or telemetry message type, by indexing and organizing in Message Broker topics, indexing the information the right way. | |||||||||||||
| Public Key Derived HMAC for JOSE | ||||||||||||||
|
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). | |||||||||||||
| Reclassifying SIIT-DC (RFC7755) to Internet Standard | ||||||||||||||
|
This document reclassifies Stateless IP/ICMP Translation for IPv6 Data Center Environments ([RFC7755]) to Standards Track and subsquently to Internet Standard. | |||||||||||||
| Reclassifying SIIT-DC-DTM (RFC7756) to Internet Standard | ||||||||||||||
|
This document reclassifies Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode ([RFC7756]) to Standards Track and subsquently to Internet Standard. | |||||||||||||
| 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. | |||||||||||||
| Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers | ||||||||||||||
|
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. | |||||||||||||
| IP/ICMP Translation Algorithm | ||||||||||||||
|
This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. | |||||||||||||
| Updates to SMTP related IANA registries | ||||||||||||||
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. | |||||||||||||
| RTP/SDP for Opus Multistream | ||||||||||||||
|
This document specifies RTP/SDP signaling for Opus multistream (multi-channel) operation, enabling negotiation of layouts such as 5.1 and 7.1 in real-time communications. It defines an SDP encoding name and format parameters to describe multistream configurations, and specifies Offer/Answer procedures for interoperable negotiation. This document extends the Opus RTP payload format defined in [RFC7587] and reuses the channel-mapping concepts defined for the Ogg container in [RFC7845]. | |||||||||||||
| Private External Message extensions for Messaging Layer Security (MLS) | ||||||||||||||
|
MLS groups that use private handshakes lose member privacy when sending external proposals. This document addresses this shortcoming by encrypting external proposals using an HPKE public key derived from the epoch secret. It also provides a mechanism to share this key and protect it from tampering by a malicious intermediary. | |||||||||||||
| Ingress Replication BUM flag in VXLAN | ||||||||||||||
|
This document proposes the allocation of an “Ingress Replication BUM” flag in the VXLAN Flags IANA registry and defines its use in EVPN networks that employ VXLAN tunnels with ingress replication to forward broadcast, unknown and multicast traffic. | |||||||||||||
| Congestion Notification for Pause | ||||||||||||||
|
This document describes the necessity and feasibility to introduce a mechanism of congestion notification for pause. After receiving the L2 pause frames from the destination data center gateway, the egress provider edge node sends the congestion notifications to the upstream provider nodes and the ingress provider edge node in a format defined in this document. The upstream provider nodes and the ingress provider edge node must pause the forwarding of IP flows identified by the congestion notifications. And then the ingress provider edge node may send the L2 pause frames to the source data center gateway. | |||||||||||||
| A YANG Data Model for network energy efficiency | ||||||||||||||
|
This document defines the YANG data model for network energy efficiency management, used to maintain network energy efficiency attributes, including device-level, board-level, and port-level. | |||||||||||||
| BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6) | ||||||||||||||
|
IGP Flexible Algorithm (Flex-Algo) provides a mechanism for IGP nodes to compute the best paths according to a set of constraints in both the topology and computation metrics. Segment Routing over IPv6 (SRv6) can be used as one of the data plane of IGP Flex-Algo. In SRv6 networks, services may be carried across multiple network domains which are under the same administration. For some services, it is expected that the an end-to-end inter-domain path can be computed according to the same constraints (such as low latency) defined by Flex-Algo. This document describes BGP extensions to advertise SRv6 locators as IPv6 prefixes, together with the associated algorithm across the AS boundary. | |||||||||||||
| MPLS Network Action for Deterministic Networking | ||||||||||||||
|
This document specifies formats and mechanisms for using MPLS Network Actions (MNA) to support Deterministic Networking (DetNet) services, including bounded latency, low loss and in-order delivery. It defines MPLS In-Stack and Post-Stack MNA for carrying DetNet-specific information, such as flow identification, sequence number, and latency information, which are forwarded over an MPLS technology- based network domain. | |||||||||||||
| Proxy Load Balancing in the Remote Authentication Dial In User Service (RADIUS) Protocol | ||||||||||||||
|
This document describes a few methods which can assist operators of proxies in the in the Remote Authentication Dial In User Service (RADIUS) Protocol. The methods described here improve proxy load balancing and rate limiting, without requiring any changes to the underlying protocol. While these methods have been shown to work in practice, there has been insufficient experience with them to publish this document either as standards track, or as a best current practice. | |||||||||||||
| Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) | ||||||||||||||
|
In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements. | |||||||||||||
| RPKI Trust Anchor Constraints | ||||||||||||||
|
Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) are commonly configured with five Trust Anchors (TAs), one for each of the Regional Internet Registries (RIRs). Each TA operator is able to make arbitrary RPKI statements about resources independently of the other TA operators: for example, one TA could issue a Route Origin Authorization (ROA) for resources that have actually been assigned to another TA. This document specifies a protocol that allows a set of TAs to make signed statements that assert their consensus as to the resources for which each TA is authoritative. | |||||||||||||
| Path Energy Traffic Ratio API (PETRA) Augmented | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio and other energy-related metric for a given network path. | |||||||||||||
| Signaling Alternative Labels for BGP Prefixes | ||||||||||||||
|
A single MPLS label or a label stack is advertised along with an address prefix as part of the NLRI belonging to labeled address families such as Labeled Unicast (RFC 8277), VPN (RFC 4364), etc. This document specifies a method to advertise one or more additional, alternative labels for a set of address prefixes using the Next Hop Dependent Characteristics (NHC) attribute. | |||||||||||||
| OAuth 2.0 Delegated Authorization | ||||||||||||||
|
Delegated authorization enables a client to delegate a subset of its granted privileges to a subordinate access token (also known as a delegated access token). This mechanism allows the client to securely delegate authorization to a delegated party while maintaining fine-grained control over delegated permissions. | |||||||||||||
| An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems | ||||||||||||||
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. | |||||||||||||
| Integration of Network Management Agent (NMA) into ACTN-Based Optical Network | ||||||||||||||
|
With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. | |||||||||||||
| A YANG Data Model for Interface to Network Security Functions (I2NSF) Analytics Interface | ||||||||||||||
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-nmrg-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. | |||||||||||||
| BGP Flow Specification Extension for Feedback Binding | ||||||||||||||
|
This document specifies a BGP Flow Specification extension that conveys per-route feedback binding for a FlowSpec route using the BGP Extended Community attribute. The proposed mechanism introduces a single Feedback Action, encoded as a Generic Transitive Extended Community, which enables downstream routers to report telemetry information or operational events associated with a FlowSpec rule. The Feedback Action carries parameters including a Feedback Identifier (FID), a window exponent (WINC) that defines the periodic aggregation interval, an event flag, and a scope selector to control where feedback is generated. These parameters are attached to the FlowSpec route and are propagated across AS boundaries unchanged. This document focuses on the signaling aspect; a companion document may define how feedback information is exported as part of a network telemetry framework (e.g., leveraging the BGP Monitoring Protocol (BMP)) or equivalent mechanisms to report periodic and event-driven feedback keyed by the FID. | |||||||||||||
| SRv6 SFC Deployment Options | ||||||||||||||
|
This document mainly introduces the factors to consider for supporting SRv6 SFC from the aspects of deployment and reliability methods. | |||||||||||||
| Source Address Validation at Intra-domain Network Boundary Using BGP | ||||||||||||||
|
This document proposes a solution for Source Address Validation (SAV) at the intra-domain network boundary using BGP. Routers at the boundary automatically generate accurate SAV rules by using routing information and SAV-specific information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document also introduces BGP extensions for communicating SAV- specific information among routers at the boundary. | |||||||||||||
| Interface to In-Network Computing Functions (I2ICF): Problem Statement | ||||||||||||||
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. | |||||||||||||
| A Framework for the Interface to In-Network Computing Functions (I2ICF) | ||||||||||||||
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. | |||||||||||||
| Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols | ||||||||||||||
|
This document outlines use cases and desirable properties for integrating remote attestation (RA) capabilities with secure channel establishment protocols, with an initial focus on Transport Layer Security (TLS) v1.3 Handshake. Traditional peer authentication in TLS establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about its current state, including the state of its trusted computing base (TCB). This document explores specific use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. From these use cases, it specifies a set of essential properties the protocol solution must have, including cryptographic binding to the TLS connection, evidence freshness, and flexibility to support different attestation models. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. | |||||||||||||
| Problem Statement of Zero Trust Deployment in Telecom Network Environments | ||||||||||||||
|
Zero Trust, as a security paradigm, has achieved global practical consensus. However, its large-scale deployment in telecommunications network environments presents unique challenges. Operationally standards tailored to the specific requirements of telecom networks are needed. | |||||||||||||
| Distributed Inference Network (DIN) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
This document describes the problem statement, use cases, and requirements for a "Distributed Inference Network" (DIN) in the era of pervasive AI. As AI inference services become widely deployed and accessed by billions of users, applications and devices, traditional centralized cloud-based inference architectures face challenges in scalability, latency, security, and efficiency. DIN aims to address these challenges by leveraging distributed edge-cloud collaboration, intelligent scheduling, and enhanced network security to support low- latency, high-concurrency, and secure AI inference services. | |||||||||||||
| Cross-device Communication Framework for AI Agents in Network Devices | ||||||||||||||
|
With the development of large language models (LLM), AI Agent software continues to emerge. AI agents deployed on different network devices need to collaborate to accomplish some complex tasks, such as network measurement and network troubleshooting. This collaboration requires cross-device communication between AI agents. This document proposes a cross-device communication framework for AI agents in network devices, and analyzes the requirements for the communication protocol. | |||||||||||||
| RPKI Repository Delta Protocol (RRDP) Delta File Retention Policy | ||||||||||||||
|
This document updates RFC 8182 (The RPKI Repository Delta Protocol) by specifying an optimized delta file retention policy based on client access patterns. The proposed mechanism allows RRDP servers to maintain only the delta files required by active clients, reducing storage requirements while maintaining compatibility with existing clients. By tracking which serial numbers are being requested by active clients, the repository can determine the minimum serial number needed by any client and safely prune delta files that update from earlier serial numbers. The proposed mechanism provides several benefits, including reduced storage requirements, smaller notification files, and more efficient use of bandwidth and processing resources. It also maintains backward compatibility with existing RRDP clients, requiring no changes to client implementations. | |||||||||||||
| WIMSE Applicability for AI Agents | ||||||||||||||
|
This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. | |||||||||||||
| Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation | ||||||||||||||
|
The Model Context Protocol (MCP) is an open standard that enables Large Language Model (LLM) applications to seamlessly integrate with external data sources and tools by exposing Resources, Prompts and Tools in a JSON-RPC 2.0 transport. This document describes a mapping of MCP roles, primitives and security model to the network management domain so that network devices act as MCP servers and network controllers act as MCP clients. The goal is to provide an intent- based, conversational and secure approach for automated network troubleshooting, configuration validation, and closed-loop remediation without inventing new protocols or device agents. | |||||||||||||
| Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens | ||||||||||||||
|
This document defines a profile for using OAuth Transaction Tokens in Agent-to-Agent (A2A) communication scenarios. The profile specifies how A2A call chain context can be embedded within Transaction Tokens to maintain agent identity, authorization context, and execution flow across distributed agent workloads within trusted domains. | |||||||||||||
| Hashing Authentication Credentials in EDHOC | ||||||||||||||
|
This document defines a COSE header parameter which signals that an authentication credential is replaced by the hash of the authentication credential in the protocol message computations. This further relaxes the need for transporting authentication credentials in EDHOC, which reduces protocol message sizes and improves performance in constrained networks. | |||||||||||||
| MCP-based Network Measurement Framework: Using Model Context Protocol for Intelligent Network Measurement | ||||||||||||||
|
This document proposes a framework for intelligent network measurement using the Model Context Protocol (MCP). By treating network devices as MCP servers and network controllers as MCP clients, this framework enables natural language-driven, AI-assisted network measurement operations. The framework leverages MCP's standardized communication protocol to provide real-time network performance monitoring, intelligent fault diagnosis, topology discovery, and automated measurement workflows. This document describes the architecture, use cases, and security considerations for implementing MCP-based network measurement systems. | |||||||||||||
| 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. | |||||||||||||
| Generic Event Notification (GEN) for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
This document defines a new BMP message type: the Generic Event Notification (GEN). The BMP GEN message provides a flexible mechanism for reporting a wide variety of events related to BGP at different levels of hierarchy, such as routing instance, AFI/SAFI, or peer level. The BMP GEN message enables operators and automated systems to receive detailed context for operational events, such as policy triggers, administrative interventions, and state management notifications (e.g., RIB view unmonitor events). | |||||||||||||
| SRv6 OAM Deployment Consideration | ||||||||||||||
|
This document introduces common issues to consider when implementing SRv6 OAM, as well as various solutions. | |||||||||||||
| Remote Attestation for Trustworthy Workload Identity | ||||||||||||||
|
Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. | |||||||||||||
| Addressing Recommendations for SRv6 | ||||||||||||||
|
This document describes SRv6 addressing for NEXT-CSID locator format. It introduces concepts of Blocks, Sets, and Node IDs, and explains how summarization boundaries and flexible algorithm support can be implemented for both small and large networks. | |||||||||||||
| Motivations and Problem Statement of Agentic AI for network management | ||||||||||||||
|
This document outlines the key objectives of introducing Agentic AI to the field of network management and highlights the fundamental issues with existing technologies that must be addressed to achieve these goals. It emphasizes the necessity for relevant groups within the IETF/IRTF and presents the core technological areas requiring standardization. The aim of Agentic AI is to facilitate a paradigm shift in which multiple autonomous AI agents collaborate to fully automate network operation, management and security. | |||||||||||||
| AI Agent Architecture for DTN Digital Twin Network | ||||||||||||||
|
This document proposes an AI agent architecture for Digital Twin Network (DTN) that integrates AI agents with digital twin technology. The architecture extends the traditional DTN architecture by incorporating autonomous AI agents at each component level, enabling more intelligent and adaptive network management capabilities. | |||||||||||||
| Optimized Use of BIER in AIML Data Centers | ||||||||||||||
|
Use of multicast in AI Data Centers (AIDC) is getting attention for efficient large-scale distribution of the same data to many receivers, given the collectives like All2All and AllReduce. Emerging technologies like In Network Compute(INC) can also benefit from using in-network-distribution of the packets by offloading the distribution of the flows to the network. Given the bursty nature of short-lived all2all flows, BIER is a very good multicast technology for AIDC because it does not need the per-establishment of the multicast tree states. This document discusses further optimization of BIER use in AIDC or similar deployment scenarios, and updates RFC4604 by specifying an IGMP/MLD extension for sources to report receiver information to the First Hop Routers. The extension can be useful and is only needed when the source cannot impose the BIER encapsulation. | |||||||||||||
| Framework for AI Agent Networks | ||||||||||||||
|
This document defines the framework of AI agent networks based on Agent Network Protocol (ANP) protocol. [ANP] It provides the basic functions that needs to support AI agent communication in the AI agent networks within the trust domain. | |||||||||||||
| Automatic Network Congestion Relief in GeneRic Autonomic Signaling Protocol (GRASP) | ||||||||||||||
|
This draft defines a method for automatic congestion relief using the Grasp protocol. In operator networks, in response to network failures such as fiber optic cable faults and optical module malfunctions, network devices can automatically respond and achieve real-time self-healing, thereby ensuring the stable operation of the network. | |||||||||||||
| Fast Notification Problem Statement | ||||||||||||||
|
Modern networks require adaptive traffic manipulation including Traffic Engineering (TE), load balancing, flow control and protection etc. to support applications like AI training and real-time services. A good and timely understanding of network operational status, such as congestion and failures, can help improve utilization, reduce latency, and enable faster response to critical events. This document describes the existing problems and why the IETF may need a new set of fast notification related solutions to support any high- throughput, low-latency and lossless application. | |||||||||||||
| A Standard for Claiming Transparency and Falsifiability | ||||||||||||||
|
This document specifies a transparency metadata interface format that allows a system to make claims about its levels of transparency and falsifiability. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/sarahdeh/draft-TMIF. | |||||||||||||
| Precise ECN in WAN | ||||||||||||||
|
This draft defines the precise ECN during used in WAN. With the growing demand for AI computing power, the computational capacity of a single Artificial Intelligence Data Center (AIDC) can no longer meet the requirements of large-scale model training. This has led to the emergence of cross-AIDC distributed model training, driving the need for transmitting RoCEv2 packets over WAN networks. AI training is highly sensitive to network packet loss, where even minimal packet loss can significantly degrade training efficiency. Additionally, elephant flows and extreme concurrent traffic impose higher demands on network performance. ECN achieves active feedback of network congestion by setting ECN flag bits in the header of IP packets, which is an effective traffic control method. RFC6040 introduces the application of ECN in WAN. However, due to the much higher end-to-end delay in WAN than in DC, and the frequent occurrence of instantaneous traffic bursts in WAN, it is easy to trigger ECN at the wrong time. This draft focuses on the precise use of ECN in WAN, by introducing different reactions of ECN in different WAN transmission scenarios | |||||||||||||
| Single Signature KeyPackages | ||||||||||||||
|
Single Signature KeyPackages improve the overhead of creating, transmitting and verifying MLS KeyPackages by removing one signature. | |||||||||||||
| Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems | ||||||||||||||
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) in Cooperative Intelligent Transportation Systems (C-ITS). For example, in the context of Vehicle-to-Everything (V2X) communications, efficient management of Vehicle-to-Vehicle (V2V) communications and their integration with C-ITS can greatly benefit from in-network computing. By leveraging ICFs, it becomes possible to optimize real- time communication, streamline traffic management, and enhance data processing and security services at the network edge. Moreover, by incorporating the Agent-to-Agent (A2A) communication paradigm, intelligent agents within vehicles, Roadside Units (RSUs), and network domains can directly collaborate to negotiate resources, exchange contextual information, and coordinate computing tasks, enabling adaptive and scalable orchestration across multi-domain C-ITS environments. | |||||||||||||
| Service Instance Deployment based on Integrated Network and Compute Metrics | ||||||||||||||
|
The deployment of service instances across distributed interconnected edge-cloud environments can be optimized in terms of performance expectations and Service Level Objectives (SLOs) satisfaction when performed taken into account both network and compute metrics. In order to do so, this document primarily concentrates on existing standardized mechanisms, namely ALTO and CATS, to facilitate such integration of metrics. The ALTO protocol can be extended to expose compute metrics from a cloud manager to a network orchestrator or as part of the network and cost maps, enabling improved deployment of compute service instances based on joint awareness of both network and computing information. This document proposes protocol extensions, workflows, and operational considerations for ALTO enhancements using CATS metrics. | |||||||||||||
| Definition for BMP Multiple Peer Header | ||||||||||||||
|
This document proposes a format of multiple peer header for aggregating BMP messages. It can be used to compress multiple BMP messages with per-peer header into one aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead. | |||||||||||||
| OAM for EVPN over SRv6 | ||||||||||||||
|
RFC 9489 describes Operation, Administration, and Maintenance (OAM) mechanisms for detecting data plane failures using Label Switched Path (LSP) Ping in MPLS-based Ethernet VPN (EVPN) networks. However, there is no effective OAM mechanism for detecting data plane failures in SRv6-based EVPN networks. This document proposals OAM mechanisms for SRv6-based EVPN networks. | |||||||||||||
| An Integrated Security Service System for 5G Networks using an I2NSF Framework | ||||||||||||||
|
This document presents an integrated framework for automated security management in 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system leverages Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated into enforceable network and application policies. Network-level policies are delivered to 5G core components via the Network Exposure Function (NEF), while application-level policies are enforced directly on a User Equipment (UE) through distributed IBN Controllers. This architecture supports adaptive, context-aware, and distributed policy enforcement, enabling real-time response to dynamic edge conditions and user mobility scenarios such as handovers. By integrating closed-loop monitoring and analytics, the system ensures consistent and autonomous security across heterogeneous 5G environments. | |||||||||||||
| Agents Networking Architecture for Enterprise and Broadband | ||||||||||||||
|
This document introduces agents networking architecture and defines the core components of agent networking, as well as typical interactions among these key components. | |||||||||||||
| 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. | |||||||||||||
| RESTful Provisioning Protocol (RPP) Data Objects | ||||||||||||||
|
This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up IANA RPP Data Object Registry to describe and catalogue them. Specifically, it details the logical structure, constraints, and protocol operations (including their inputs and outputs) for foundational resources: domain names, contacts, and hosts. In accordance with the RPP architecture [I-D.kowalik-rpp-architecture], these definitions focus entirely on the semantics, remaining independent of any specific data representation or media type (e.g., JSON or XML). | |||||||||||||
| Hybrid Digital Signatures with Strong Unforgeability | ||||||||||||||
|
This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF- CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security. In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure. | |||||||||||||
| IPv6-Resolved IPv4 Gateway | ||||||||||||||
|
This document requests the allocation of a new IPv4 special-purpose address from the IANA IPv4 Special-Purpose Address Registry. The proposed address, 192.0.0.11/32, is intended to serve as a signal to IPv4 hosts in IPv6-only networks that the link-layer resolution for the default gateway should be derived from the IPv6 default gateway learned via IPv6 Router Advertisements and Neighbor Discovery. This approach enables IPv4 communication without requiring IPv4 subnets or the use of ARP. It maintains backward compatibility with existing IPv4 host software that expects a default gateway IP address, while avoiding the need to implement legacy link-layer protocols. | |||||||||||||
| MPLS for AIDC Probing | ||||||||||||||
|
This document describes a method for using Multi-Protocol Label Switching (MPLS) encapsulation to perform scalable and vendor- agnostic network probing within AI/ML data centers. The goal is to detect and isolate gray failures—non-deterministic hardware and software faults—in large-scale lossless networks. The approach enables targeted probing at per-link and per-node granularity, independent of IP/BGP control plane operation, and is extensible to Various CLOS topologies. | |||||||||||||
| Mothma: Generic Instantiated PQ/T Hybrid Signatures | ||||||||||||||
|
This document specify Mothma as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Digital Signatures. The goal is to provide a generic hybrid signature pattern that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on combinations of the traditional EdDSA, ECDSA and RSA methods with the post-quantum methods of ML-DSA, SLH-DSA, XMSS and LMS. | |||||||||||||
| Test Vectors for CBOR Encoded X.509 (C509) Certificates | ||||||||||||||
|
This document contains examples of CBOR encoded X.509 (C509) certificates, certificate (signing) requests, and certificate request templates. | |||||||||||||
| Extension to Connect-IP for static IP header compression | ||||||||||||||
|
This document specifies an extension for IP header compression when using Connect-IP proxying. | |||||||||||||
| Scheduling Network Resources for Machine Learning Clusters | ||||||||||||||
|
Large Language Models (LLMs) are pushing the boundaries of technology. The scale that they have reached currently vastly exceeds the capacity of any single compute unit (XPU); this requires a distributed approach where multiple XPUs are connected via a "backend" network, typically in a single data center. We are approaching the point where the scale exceeds that of a single data center, thus requiring multiple such data centers connected via a "data center interconnect" network. Training and inferencing are expensive and critical operations, thus they are typically scheduled, i.e., the (compute) resources they need are carefully estimated, allocated and deployed so that these resources are efficiently used. However, while compute investment in these LLM processing clusters dwarfs that of networks, it is becoming increasingly clear that the latter can greatly impact the former. This has been the focus of recent conferences, including the fantel Birds of a Feather meeting in IETF 123, @Scale: Networking and Open Compute Project. This memo proposes that the same care be taken regarding networking resources: that they are estimated, allocated and deployed alongside compute resources; that they have contingency plans in case of network glitches; and that a holistic view be taken in order to optimize the running of training and inferencing jobs. | |||||||||||||
| Unified Optical Networks and AI Computing Orchestration (UONACO) Problem Statement,Use Cases and Requirements | ||||||||||||||
|
Distributed artificial intelligence (AI) computing is increasingly deployed across geographically dispersed AI data centers (AIDCs) to meet the scale and performance demands of modern AI workloads. In such environments, the efficiency of distributed training, inference, and remote service access depends critically on tight coordination between optical transport networks and compute orchestration systems. However, today's infrastructure operates with isolated control planes: optical networks lack awareness of dynamic compute requirements, while compute schedulers have no visibility into real- time network conditions such as latency, bandwidth, or congestion. This decoupling leads to suboptimal resource utilization, degraded job performance, and inefficient scaling. This document presents the problem statement, outlines three representative use cases—distributed AI training, distributed AI inference, and remote AI service access—and specifies the requirements for Unified Optical Networks and AI Computing Orchestration (UONACO). The goal is to enable bidirectional awareness, joint resource abstraction, and synchronized control across the compute-optical boundary, thereby supporting intent- driven, end-to-end provisioning of AI services over wide-area optical infrastructures. | |||||||||||||
| Remote Attestation with Exported Authenticators | ||||||||||||||
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. | |||||||||||||
| BGP extensions for SRv6/MPLS Transport Interworking | ||||||||||||||
|
This document defines the BGP extensions required to provide transport interworking between SRv6 and MPLS in SRv6 deployment. | |||||||||||||
| A Control Framework for Unified Optical Networks and AI Computing Orchestration (UONACO) | ||||||||||||||
|
This document presents the control framework for Unified Optical Networks and AI Computing Orchestration (UONACO). Specifically, it defines the AI computing service model over wide-area networks, outlines the UONACO control architecture, identifies a set of UONACO components and interfaces, and describes their interactions. | |||||||||||||
| Anonymous Tokens with Hidden Metadata | ||||||||||||||
|
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 | ||||||||||||||
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Tokens with Hidden Metadata (ATHM) protocol. | |||||||||||||
| Graph based Meta Schema for collaborative Operations | ||||||||||||||
|
Graph based Meta Schema for collaborative Operation | |||||||||||||
| DNS Protocol Modifications for Delegation Extensions | ||||||||||||||
|
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document describes modifications to the Domain Name System (DNS) protocol to permit a range of resource record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. | |||||||||||||
| EVPN Multi-Active Multihoming | ||||||||||||||
|
EVPN supports All-Active and Single-Active multihoming, where either all multihoming PEs are active or only one is active. In some situations, it is desired to support Multi-Active with multiple yet not all active PEs. This document specifies the Multi-Active multihoming - some multihoming PEs are in All-Active mode while others are in Single-Active mode on the same multihoming Ethernet Segment, and ingress PEs load-balance to those in All-Active mode. | |||||||||||||
| HTTP Signature Component for TLS Channel Binding | ||||||||||||||
|
A derived component is specified for HTTP Message Signatures that binds the signature to the underlying secure channel (TLS over TCP or QUIC), thereby ensuring a signed message transmitted over one channel cannot be retransmitted over another. The component consists of key material exported from TLS. | |||||||||||||
| Agents Networking Scenarios in Enterprise and Broadband Networks | ||||||||||||||
|
This document describes agents networking scenarios in enterprise and home broadband networks. These scenarios differ from 6G and Internet scenarios. Since the agentic service is still at the emerging stage, especially in enterprise and home broadband networks, the scenarios are mostly based on reasonable assumptions. | |||||||||||||
| Defend the World from IoT Remote-threats & Malware | ||||||||||||||
|
Internet of Things (IoT) devices are commonly added to home networks without fully understanding which services (hosts, ports, protocols) are being provided or consumed for those devices to operate. As a result, they are essentially unmanaged threats with full access to that network and the internet. The Defend the World from IoT Remote- threats & Malware (DWIRM) extension to DHCP provides a framework for IoT devices to negotiate services that the local router in turn enforces as policy. | |||||||||||||
| Metadata Constrained Distribution | ||||||||||||||
|
This document defines the Metadata-Filter (MDF) Subsequent Address Family Identifier (SAFI). A BGP speaker uses MDF to signal its lack of interest in receiving service metadata attributes on routes that carry specified Route Targets (RTs), while leaving reachability unchanged. | |||||||||||||
| Model Context Protocol over Media over QUIC Transport | ||||||||||||||
|
This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP is a protocol that enables seamless integration between language model applications and external data sources and tools. MOQT provides efficient, low-latency, publish-subscribe media delivery over QUIC and WebTransport. This specification describes the mapping of MCP messages onto MOQT objects and defines the procedures for establishing and maintaining MCP sessions over MOQT. | |||||||||||||
| Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol | ||||||||||||||
|
This document specifies how the Agent-to-Agent (A2A) protocol can be transported over Media over QUIC Transport (MOQT). MOQT provides a publish/subscribe model over QUIC that enables efficient real-time communication between AI agents, supporting the A2A protocol's requirements for discovery, negotiation, and collaboration while leveraging MOQT's streaming capabilities and built-in prioritization mechanisms. | |||||||||||||
| SRP Remove All Services EDNS(0) option | ||||||||||||||
|
This document describes a new EDNS(0) option for an SRP Update to remove all previously registered services for a hostname before adding new services for that same hostname. This allows an SRP requester to replace all its previous service registrations with new ones using a single SRP Update. | |||||||||||||
| A code to describe satellite constellations | ||||||||||||||
|
When considering a satellite constellation forming a non-terrestrial network, the characteristics of this constellation heavily influences the network topology it forms. To improve the analysis of such non- terrestrial networks across various tools developed by the network community, this document proposes a notation to describe common constellation patterns. In addition, this document may serve as an introduction to satellite constellations for IETF participants. | |||||||||||||
| MIMI Identifiers | ||||||||||||||
|
TODO Abstract | |||||||||||||
| SCONE TCP Option | ||||||||||||||
|
This document describes a TCP option that permits network elements to provide TCP endpoints advice on rate limits within the network. The functionality for TCP is analogous to SCONE packets within the QUIC protocol. | |||||||||||||
| Reliability Considerations for Delay-Tolerant Networks | ||||||||||||||
|
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). | |||||||||||||
| Guidelines for Security Considerations of RATS | ||||||||||||||
|
This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. | |||||||||||||
| Equipment Capability Application | ||||||||||||||
|
This document applies the generalized capability principles to the description of equipment (a physical thing) with applied data (configuration state and code (software, firmware etc.)) and shows how such capability specifications integrate with base inventory and entitlement models as defined in Network Inventory, Software Extension and Entitlement YANG models. The approach is examined by example, focusing on how the potential capabilities of each equipment type-version with applied data are described, how these map to entitlements (licensed or policy- controlled subsets of capabilities), and how they are instantiated as inventory items. The explanation covers both the capabilities of equipment in terms of physical properties and the capabilities of equipment with applied data in terms of resultant emergent functionality. | |||||||||||||
| Generalized Capability Principles | ||||||||||||||
|
This document introduces a framework for capability modeling based on the specification and refinement principles established in ITU-T G.7711 Annex G (also published as ONF TR-512.7 see latest release) and the modeling boundaries work documented in draft-davis-netmod- modelling-boundaries. The framework defines how component–system capabilities can be explicitly described and refined via a process of pruning, refactoring, and occurrence formation. These capability definitions can target detailed operational considerations, system interactions, licensing, abstract product declarations, or sales and marketing. The framework supports modular, layered, and fractal declarations of networked behavior, and provides a foundation for a suite of future IETF drafts aligned with ongoing work on photonic plug manifests, entitlement/licensing, IVY equipment modeling, energy/thermal considerations and related domains. | |||||||||||||
| Privacy Pass Issuance Protocol for Anonymous Credit Tokens | ||||||||||||||
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Credit Tokens (ACT) protocol. | |||||||||||||
| x509 Decentralized Identifier | ||||||||||||||
|
Some abstract | |||||||||||||
| HMAC Based Hybrid Key Combiners for Multiple Keys | ||||||||||||||
|
As a fundamental building block in security protocols, a key combiner is used to combine two or more input cryptographic keys, some potentially compromised, into a single pseudorandom output key. Most of the existing key combiners are for two input keys. This draft specifies two proveably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys are produced by different algorithms or even different approaches [RFC9370], [ETSI25]. Namely, here the input keys can be two or more, and the combined output key remains pseudorandom if at least one of the input keys is secure, i.e., uniformly random and unknown to an attacker. The two constructions, called HKCv1 and HKCv2, are based on the extract-then- expand paradigm of HMAC (Keyed-Hashing for Message Authentication) [RFC2104]. HKCv1 is designed for simultaneously available input keys using concatenation, while HKCv2 is tailored for scenarios where input keys arrive incrementally, using an iterative HMAC structure. [EDNOTE: .... ] | |||||||||||||
| Protocol for Crowd Sourcing Air Domain Awareness | ||||||||||||||
|
This document standardizes an architecture to enable trust to sensors that provide Air Domain Awareness. Broadcast Remote ID is used as the primary example to define data models and methods used. | |||||||||||||
| Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios | ||||||||||||||
|
Encrypted Client Hello (ECH) improves destination privacy by encrypting the Server Name Indication in TLS, but the customer's source identity-- typically the IP address and network metadata-- remains observable to intermediaries such as CDNs, hosting providers, and recursive resolvers. This document introduces the _Customer- Facing Relay (CFR)_, a lightweight, transport-agnostic relay operated by access providers to decouple customer identity from encrypted destinations. By forwarding opaque encrypted payloads (TCP or UDP) without terminating TLS or QUIC, a CFR complements ECH encryption to strengthen source privacy and reduce metadata correlation. | |||||||||||||
| Authenticated ECH Config Distribution and Rotation | ||||||||||||||
|
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them without a certificate for the public name, limiting deployment flexibility. This document specifies an authenticated ECH configuration update mechanism. Servers can deliver signed ECH configurations during the TLS handshake, allowing clients to authenticate and immediately use them for retry. The mechanism decouples ECH key distribution from transport, enabling the same signed configuration to work via DNS or TLS delivery. | |||||||||||||
| Fine-Grained Flow Control Backpressure Mechanism for Wide Area Networks | ||||||||||||||
|
This document specifies a fine-grained flow control backpressure mechanism for Wide Area Networks (WANs). The mechanism enables precise congestion notification and flow control at tenant or task granularity through extended network protocols and controller- assisted path discovery. It addresses the limitations of traditional flow control mechanisms in WAN environments by providing intelligent backpressure with detailed congestion information, with specific applicability in SRv6-based networks. | |||||||||||||
| Transmission of IPv6 over Multidrop Serial Bus/Token Passing (MS/TP) Networks | ||||||||||||||
|
Mutidrop Serial Bus/Token Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. | |||||||||||||
| Metric Normalize for IGP Flex-algo | ||||||||||||||
|
When multiple links in a network have the same metric, they can serve as ECMP equivalent links for load balancing during forwarding. However, slight fluctuations in metric values can prevent the formation of ECMP equivalent links, leading to the idle state of suboptimal links and thus wasting bandwidth resources. This document proposes a method for normalizing metrics, allowing the slight fluctuations across multiple links to be adjusted so that the resulting calculated metrics become identical. This enables the formation of ECMP equivalent links, facilitating load distribution during forwarding. | |||||||||||||
| Applicability Statement for IETF Core Email Protocols | ||||||||||||||
|
Electronic mail is one of the oldest internet applications in active use. The protocols and formats for mail transport and message formats have evolved slowly over the years. This Applicability Statement describes interaction with newer protocols. [Provided as a diff to the WG document] | |||||||||||||
| TESLA Update for GNSS SBAS Authentication | ||||||||||||||
|
This document updates TESLA [RFC4082] to current cryptographic methods for use by the International Civil Aviation Organization (ICAO) in their Global Navigation Satellite System (GNSS) Satellite- based augmentation system (SBAS) authentication protocol. The TESLA updates are to align it with current best practices. | |||||||||||||
| Base YANG Data Model for NVO3 Protocols | ||||||||||||||
|
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). | |||||||||||||
| SD-JWT-based Verifiable Credentials (SD-JWT VC) | ||||||||||||||
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. | |||||||||||||
| Token Status List (TSL) | ||||||||||||||
|
This specification defines a mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. | |||||||||||||
| OAuth 2.0 for First-Party Applications | ||||||||||||||
|
This document defines the Authorization Challenge Endpoint, which supports a first-party client that wants to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions. | |||||||||||||
| JSON Web Token Best Current Practices | ||||||||||||||
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore replaces the existing JWT BCP specification RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. | |||||||||||||
| A Data Manifest for Contextualized Telemetry Data | ||||||||||||||
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. | |||||||||||||
| Guidelines for Characterizing "OAM" | ||||||||||||||
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates [RFC6291] by adding to the guidelines for the use of the term "OAM". It does not modify any other part of [RFC6291]. | |||||||||||||
| A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests | ||||||||||||||
|
This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes. | |||||||||||||
| Publishing End-Site Prefix Lengths | ||||||||||||||
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen files which are comma-separated values (CSV) files used to specify end-site prefix lengths. This document also describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen files. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. | |||||||||||||
| Multipath Support for IGMP/MLD Proxy | ||||||||||||||
|
This document specifies the framework to support multipath reception in Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed mechanism allows IGMP/ MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. It defines static configuration methods for associating upstream interfaces with channel identifiers and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. | |||||||||||||
| Batched Token Issuance Protocol | ||||||||||||||
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. | |||||||||||||
| Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials | ||||||||||||||
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. | |||||||||||||
| Anonymous Rate-Limited Credentials | ||||||||||||||
|
This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. | |||||||||||||
| qlog: Structured Logging for Network Protocols | ||||||||||||||
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| QUIC event definitions for qlog | ||||||||||||||
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| HTTP/3 qlog event definitions | ||||||||||||||
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| QUIC Acknowledgment Frequency | ||||||||||||||
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. | |||||||||||||
| Managing multiple paths for a QUIC connection | ||||||||||||||
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It proposes a standard way to create, delete, and manage paths using identifiers. It does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. | |||||||||||||
| (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS | ||||||||||||||
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. | |||||||||||||
| Concise Reference Integrity Manifest | ||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. | |||||||||||||
| Concise Selector for Endorsements and Reference Values | ||||||||||||||
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. | |||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | ||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | |||||||||||||
| Gap Analysis,Problem Statement,and Requirements for Inter-Domain SAV | ||||||||||||||
|
This document provides a gap analysis of existing inter-domain source address validation mechanisms, describes the problem space, and defines the requirements for technical improvements. | |||||||||||||
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. | |||||||||||||
| Standard Communication with Network Elements (SCONE) Protocol | ||||||||||||||
|
This document describes a protocol where on-path network elements can give endpoints their perspective on what the maximum achievable throughput might be for QUIC flows. | |||||||||||||
| RPKI Publication Server Best Current Practices | ||||||||||||||
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. | |||||||||||||
| Trust and security considerations for Structured Email | ||||||||||||||
|
This document discusses trust and security considerations for structured email and provides recommendations for message user agents on how to deal with structured data in email messages. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Structured Email Working Group mailing list (sml@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sml/. Source for this draft and an issue tracker can be found at https://github.com/arnt/sml-trust. | |||||||||||||
| Selective Disclosure CBOR Web Tokens (SD-CWT) | ||||||||||||||
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. | |||||||||||||
| Use Cases for SPICE | ||||||||||||||
|
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. | |||||||||||||
| GLobal Unique Enterprise (GLUE) Identifiers | ||||||||||||||
|
This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers addressing the requirements identified by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. | |||||||||||||
| OpenID Connect Standard Claims Registration for CBOR Web Tokens | ||||||||||||||
|
This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. | |||||||||||||
| YANG Data Model for Segment Routing Policy | ||||||||||||||
|
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 | ||||||||||||||
|
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). | |||||||||||||
| SSH Agent Protocol | ||||||||||||||
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. | |||||||||||||
| Guidance on RESTful Design for Internet of Things Systems | ||||||||||||||
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). | |||||||||||||
| Realizing Network Slices in IP/MPLS Networks | ||||||||||||||
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. | |||||||||||||
| Common YANG Data Types for Traffic Engineering | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. | |||||||||||||
| Scalability Considerations for Network Resource Partition | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. | |||||||||||||
| IETF Network Slice Controller and its Associated Data Models | ||||||||||||||
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. | |||||||||||||
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases | ||||||||||||||
|
This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. | |||||||||||||
| Extended Key Update for Transport Layer Security (TLS) 1.3 | ||||||||||||||
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post-compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. | |||||||||||||
| The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. | |||||||||||||
| Configuring UDP Sockets for ECN for Common Platforms | ||||||||||||||
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. | |||||||||||||
| Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. | |||||||||||||
| Using off-path mechanisms for exposing Time-Variant Routing information | ||||||||||||||
|
Time-Variant Routing (TVR) involves predictable, scheduled changes to network topology elements such as nodes, links, and adjacencies that impact routing behavior over time. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). This document proposes mechanisms for exposing TVR information to both internal and external applications, focusing on off-path solutions that decouple the advertisement of scheduled changes from the routing control plane signaling. | |||||||||||||
| IPv6-Mostly Networks: Deployment and Operations Considerations | ||||||||||||||
|
This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). | |||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | ||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. | |||||||||||||
| The WebTransport Protocol Framework | ||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. | |||||||||||||
| WebTransport over HTTP/3 | ||||||||||||||
|
WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. | |||||||||||||
| WebTransport over HTTP/2 | ||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | |||||||||||||
| Transmission of IPv6 Packets over Short-Range Optical Wireless Communications | ||||||||||||||
|
[IEEE802.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. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| 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. | |||||||||||||
| Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) | ||||||||||||||
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. | |||||||||||||
| 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. | |||||||||||||
| Incremental HTTP Messages | ||||||||||||||
|
This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. | |||||||||||||
| Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs and a crypt-offset to allow for exposing inner flow information for middlebox use. | |||||||||||||
| Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) | ||||||||||||||
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key, and provides security against adaptive chosen ciphertext attacks (IND-CCA2-secure). HPKE also includes a variant that authenticates possession of a pre- shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document defines the use of HPKE with JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. | |||||||||||||
| Key Transparency Architecture | ||||||||||||||
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. | |||||||||||||
| 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. | |||||||||||||
| Subscription to Notifications in a Distributed Architecture | ||||||||||||||
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. | |||||||||||||
| 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. | |||||||||||||
| Use Cases and Practices for Intent-Based Networking | ||||||||||||||
|
This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learning and general learning are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. | |||||||||||||
| Binary Uniform Language Kit 1.0 | ||||||||||||||
|
This specification describes a uniform, decentrally extensible and efficient format for data serialization. | |||||||||||||
| 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). | |||||||||||||
| PCEP Extension for Bounded Latency | ||||||||||||||
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry the bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. | |||||||||||||
| Merkle Tree Certificates | ||||||||||||||
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. | |||||||||||||
| Considerations For Maintaining Protocols Using Grease and Variability | ||||||||||||||
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. | |||||||||||||
| A Multiplane Architecture Proposal for the Quantum Internet | ||||||||||||||
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. | |||||||||||||
| 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. | |||||||||||||
| YANG Data Model for Power-Group Aware TE Topology | ||||||||||||||
|
This document discusses the notion of a Power-Group construct as an attribute of a Traffic Engineered (TE) Link and defines a YANG data model for representing a Power-Group aware TE topology. | |||||||||||||
| 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 | ||||||||||||||
|
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. | |||||||||||||
| Zero-Trust Sovereign AI: Verifiable Geofencing & Residency Proofs for Cybersecure Workloads | ||||||||||||||
|
Modern cloud and distributed environments face significant risks from stolen bearer tokens, protocol replay, and trust gaps in transit. This document presents a framework for modernizing workload security through cryptographically verifiable geofencing, proof-of-possession, and protocol-aware residency enforcement. By binding workload identity to both geographic and host attributes, and supplementing bearer tokens with verifiable, location- and host- bound claims, the framework addresses the challenges of bearer token theft, proof-of-possession and trust-in-transit for all networking protocols. Leveraging trusted hardware, attestation protocols, and geolocation services, this approach ensures that only authorized workloads in approved locations and environments can access sensitive data or services, even in the presence of advanced threats. | |||||||||||||
| Applicability of MCP for the Network Management | ||||||||||||||
|
The application of MCP in the network management field is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose these AI integration capabilities. This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies.It explores MCP for network exposure, multiple MCP server discovery generic workflow and deployment scenarios. | |||||||||||||
| Reclassifying RFC6052 to Internet Standard | ||||||||||||||
|
This document reclassifies IPv6 Addressing of IPv4/IPv6 Translators ([RFC6052]) to Internet Standard. | |||||||||||||
| SRv6 BGP Unreachable Prefix Announcement (UPA) | ||||||||||||||
|
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. | |||||||||||||
| Selective Disclosure for Agent Discovery and Identity Management (SD- Agent) | ||||||||||||||
|
This document defines how Selective Disclosure for JWTs (SD-JWT) integrates with Agent-to-Agent (A2A) systems to provide privacy- preserving agent discovery and cryptographically verifiable identity management. It specifies the SD-Card format - an SD-JWT encoding of Agent Cards that enables selective disclosure of agent capabilities, contact information, and operational metadata while maintaining cryptographic integrity and preventing correlation across different interaction contexts. | |||||||||||||
| 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. | |||||||||||||
| IPv6 Prefix Assignment to end-users | ||||||||||||||
|
This document describes different alternatives and best current practices for assignment of IPv6 prefixes for end-user broadband networks, including considerations about point-to-point links, their size, numbering choices, pool choices, customer prefix assignment size and persistance of those assignments. | |||||||||||||
| Reservation of IPv6 Address Block 44::/16 for Amateur Radio Digital Communications (44Net) | ||||||||||||||
|
This document proposes the reservation of the IPv6 address block 44::/16 for use by the Amateur Radio Digital Communications network (44Net, also known as AMPRNet). 44Net has historically used IPv4 network 44.0.0.0/8 as a globally-unique space for amateur radio digital communications. We present the rationale for an IPv6 counterpart, detailing the unique technical and social characteristics of 44Net that distinguish it from the commercial Internet, and the global public service it enables. While 44Net operates under amateur radio licensing and usage policies (non- commercial, experimental use by licensed operators), the proposed IPv6 block will be part of the global Internet routing table to facilitate interoperability, gateways, and research. This document includes background on 44Net, justification for the 44::/16 allocation, technical requirements (routing and DNS considerations), and the IANA action requested to reserve 44::/16 for Amateur Radio use as a special-purpose IPv6 prefix. | |||||||||||||
| 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. | |||||||||||||
| Normalized API for AI Agents Calling Tools (N-ACT) | ||||||||||||||
|
This document defines a protocol that facilitates integration of tools into the design and run-time operations of AI Agents. The focus is on enterprise AI agents that need to make use of APIs exposed by third party providers. This protocol, called the Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like "enact" - defines an OpenAI spec that has two principle features - enumeration of tools and invocation of tools. The enumeration API enables a human - the AI Agent designer employed by the enterprise - to select and include tools from third-party vendors into operating procedures (also known as skills or instructions) which direct the behavior of AI Agents, including how and when to invoke those tools. The enumeration API can also be used (optionally) at run-time for the LLM to obtain tool descriptions. The second feature of the API - invocation - allows the AI Agent executor to perform the inter-domain invocation of the tool at run time. By standardizing these two API functions, the time and cost of integration of Internet APIs into AI Agents can be reduced. | |||||||||||||
| 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. | |||||||||||||
| Design of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. It pays special attention to the high jitter conditions encountered in Wi-Fi networks. The design emphasizes simplicity and avoids making too many assumption about the "model" of the network. The main control variables are the estimate of the data rate and of the maximum path delay in the absence of queues. | |||||||||||||
| Specification of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design emphasizes simplicity and avoids making too many assumptions about the "model" of the network. | |||||||||||||
| Testing of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design was validated by series of simulations, and also by initial deployments in control networks. We describe here these simulations and tests. | |||||||||||||
| The OAuth 2.1 Authorization Framework | ||||||||||||||
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. | |||||||||||||
| Identity Assertion JWT Authorization Grant | ||||||||||||||
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through a common enterprise identity provider using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. | |||||||||||||
| Applying COSE Signatures for YANG Data Provenance | ||||||||||||||
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integritu of datasets and/or data streams. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. | |||||||||||||
| PCEP extensions for SR P2MP Policy | ||||||||||||||
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaf nodes. | |||||||||||||
| 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. | |||||||||||||
| The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 | ||||||||||||||
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. | |||||||||||||
| Segment Routing IPv6 Security Considerations | ||||||||||||||
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. | |||||||||||||
| SRv6 Deployment Options | ||||||||||||||
|
When deciding to migrate a network from MPLS/SR-MPLS to SRv6, common questions involve how to go about performing the migration, what's the least amount of impact to an existing network and what existing techniques are available. This document presents various options for networks being migrated from MPLS/SR-MPLS to SRv6. | |||||||||||||
| 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. | |||||||||||||
| A well-known URI for publishing service parameters | ||||||||||||||
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record. | |||||||||||||
| 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. | |||||||||||||
| Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) | ||||||||||||||
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. | |||||||||||||
| Applicability Statement for IETF Core Email Protocols | ||||||||||||||
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. | |||||||||||||
| Updated YANG Module Revision Handling | ||||||||||||||
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. | |||||||||||||
| SIMAP: Concept,Requirements,and Use Cases | ||||||||||||||
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. | |||||||||||||
| A Mechanism for Encoding Differences in Paired Certificates | ||||||||||||||
|
This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to reconstruct the paired certificate and perform certification path validation using the reconstructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. | |||||||||||||
| Assignment of Ethernet Parameters for Bundle Transfer Protocol - Unidirectional (BTP-U) over Ethernet | ||||||||||||||
|
This memo requests Ethernet parameters for Bundle Transfer Protocol - Unidirectional [BTP-U] for use on Ethernet and Ethernet-like links. This is not intended to replace existing IP-based Convergence Layer (CLs). Rather this makes it possible to use Ethernet with BTP-U as a CL in environments where Ethernet-like operation better matches the network infrastructure or operational constraints. | |||||||||||||
| Serialization of MoQ Objects to Files | ||||||||||||||
|
This specification provides a way to save the metadata about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the metadata and payload data allows the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to clients. | |||||||||||||
| A Framework for LLM Agent-Assisted Network Management with Human-in-the-Loop | ||||||||||||||
|
This document defines an interoperable framework that facilitates collaborative network management between Large Language Models (LLMs) agents and human operators. The proposed framework introduces an enhanced telemetry module, an LLM agent decision module, and interaction data models between human operators and LLM agent-driven systems, and workflows to enforce human oversight. The approach ensures compatibility with existing network management systems and protocols while improving automation and decision-making capabilities in network operations. | |||||||||||||
| KEM-based Authentication for IKEv2 with Post-quantum Security | ||||||||||||||
|
This draft specifies a new authentication mechanism, called KEM (Key Encapsulation Mechanism) -based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2). This is motivated by the fact that some post-quantum KEMs (like ML-KEM) are more efficient than post-quantum signature algorithms (like ML-DSA). | |||||||||||||
| Challenges in Transporting Sensing Data with Media Over QUIC | ||||||||||||||
|
This document proposes leveraging Media Over QUIC (MOQ) to address the challenges of transmitting large-scale, real-time sensing data in 6G networks. By building on QUIC's low-latency and multiplexing capabilities, MOQ offers a flexible and efficient transport mechanism tailored to the dynamic and high-throughput requirements of 6G environments. The approach focuses on enabling protocol adaptability across diverse application scenarios such as autonomous driving, smart cities, and industrial IoT, while ensuring efficient data fragmentation, secure and anonymous transmission, and end-to-end QoS awareness. Through information-aware endpoints and optimized data delivery mechanisms, this solution supports scalable, reliable, and intelligent sensing data distribution in next-generation wireless networks. It is also available to other types of 6G System Data [3GPP.22.870] besides sensing data, e.g., AI data, positioning data. | |||||||||||||
| LSP Ping/Traceroute for Prefix SID in Multi-Algorithm/Multi-Topology Networks | ||||||||||||||
|
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] works well in single topology, single algorithm deployments where each Prefix SID is only associated with a single IP prefix. In multi-topology networks, or networks deploying multiple algorithms for the same IP Prefix, MPLS echo request needs to carry additional information in the Target FEC Stack sub-TLVs to properly validate IGP Prefix SID. This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix Segment ID FEC sub-TLVs to also include algorithm identification while maintaining backwards compatibility. This document also introduces new Target FEC Stack sub-TLVs for Prefix SID validation in multi-topology networks. | |||||||||||||
| Hybrid Ed25519 with ML-DSA-65 for Secure Shell (SSH) | ||||||||||||||
|
This document describes the use of Ed25519 with ML-DSA-65 as a hybrid digital signature in the Secure Shell (SSH) protocol. | |||||||||||||
| ipv7 | ||||||||||||||
|
ipv7 | |||||||||||||
| Distributed Roaming and Mobility Problem Statement | ||||||||||||||
|
This document describes the problem statement for enabling roaming across a distributed set of heterogenous wireless access networks. | |||||||||||||
| A Scoping Mechanism for Fast Notification Using IGP Areas | ||||||||||||||
|
Fast Notification for Traffic Engineering and Load Balancing (FaNTEL) enables real-time dissemination of network events such as link failure, congestion, or load imbalance. However, unbounded flooding of FaNTEL messages can lead to control plane overload and state explosion. This document defines a scoping mechanism for FaNTEL based on IGP area boundaries. It formally specifies the concept of a FaNTEL Area, the structure of scoped notification messages, and the precise forwarding behavior within and across areas. The mechanism leverages existing IGP topological partitions (e.g., OSPF areas, IS-IS levels) to contain message propagation, ensuring rapid local response while preventing unnecessary global churn. This document focuses exclusively on the propagation model and provides normative rules for implementation. | |||||||||||||
| OAuth 2.0 JWT Authorization Grant with DPoP Binding | ||||||||||||||
|
This specification defines a new OAuth 2.0 authorization grant type that uses a JSON Web Token (JWT) assertion to request an access token that is bound to a specific key using the Demonstration of Proof-of- Possession (DPoP) mechanism. This provides a higher level of security than a simple bearer token, as the client must prove possession of the key to use the access token. | |||||||||||||
| Network Delivery Time Control | ||||||||||||||
|
This document describes Network Delivery Time Control (NDTC), a rate adaptation algorithm for real-time video streaming suited for interactive applications like cloud gaming. NDTC leverages the Frame Dithering Available Capacity Estimation (FDACE) heuristic, which estimates available path capacity without inducing congestion. The algorithm dynamically adjusts frame sizes and transmission times to ensure timely delivery, while also responding to conventional congestion signals. | |||||||||||||
| RPKI-based Validation with Prioritized Resource Data | ||||||||||||||
|
RPKI ROAs and other digitally signed objects provide a practical solution to validate BGP routes for preventing route hijacks. During ROV operations, validation data may be sourced not only from issued ROAs but also from other local sources. These data sources can vary in terms of credibility, and ROV operations may therefore require different response actions for invalid or unknown routes. This document takes ROV as an example to describe a flexible RPKI-based route validation using multi-priority data, and outlines relevant use cases, framework, and requirements for ROV operations that involve multi-priority data. | |||||||||||||
| PQC Continuity: Downgrade Protection for TLS Servers Migrating to PQC | ||||||||||||||
|
As the Internet transitions toward post-quantum cryptography (PQC), many TLS servers will continue supporting traditional certificates to maintain compatibility with legacy clients. However, this coexistence introduces a significant vulnerability: an undetected rollback attack, where a malicious actor strips the PQC or Composite certificate and forces the use of a traditional certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a client to cache a server's declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, clients enforce that cached commitment and reject traditional-only certificates that conflict with it. This mechanism, inspired by HTTP Strict Transport Security (HSTS) but operating at the TLS layer provides PQC downgrade protection without requiring changes to certificate authority (CA) infrastructure. | |||||||||||||
| Adapting Constrained Devices for Post-Quantum Cryptography | ||||||||||||||
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. | |||||||||||||
| Terminology and processes for initial security setup of IoT devices | ||||||||||||||
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. | |||||||||||||
| TLS/DTLS 1.3 Profiles for the Internet of Things | ||||||||||||||
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. | |||||||||||||
| 464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations | ||||||||||||||
|
464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) by further defining CLAT node behavior and IPv6 Customer Edge Routers to Support IPv4-as-a-Service by providing recommendations for the node developers on enabling and disabling CLAT. | |||||||||||||
| Semantic Definition Format (SDF) modeling for Digital Twin | ||||||||||||||
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. | |||||||||||||
| Weighted Multi-Path Procedures for EVPN Multi-Homing | ||||||||||||||
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. | |||||||||||||
| EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols | ||||||||||||||
|
The existing EVPN multi-homing load-balancing modes do not adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, etc. This document defines a new multi-homing mechanism to support these loop-preventing Layer-2 protocols. | |||||||||||||
| BGP link bandwidth extended community use cases | ||||||||||||||
|
BGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations. | |||||||||||||
| CPace,a balanced composable PAKE | ||||||||||||||
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. | |||||||||||||
| Verifiable Distributed Aggregation Functions | ||||||||||||||
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). | |||||||||||||
| DULT Threat Model | ||||||||||||||
|
Lightweight Location-tracking Tags are in wide use to allow users to locate items. These Tags function as a component of a Crowdsourced Network in which Devices belonging to other network users (e.g., phones) report which Tags they see and their location, thus allowing the Owner(s) of the Tag to determine where their Tag was most recently seen. While there are many legitimate uses of these Tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect Unwanted Tracking must incorporate an understanding of the Unwanted Tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of Unwanted Tracking and potential attacks against Detection of Unwanted Location Tracking (DULT) protocols. The document defines what is in and out of scope for the Unwanted Tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect Unwanted Tracking. | |||||||||||||
| AS Path Prepending | ||||||||||||||
|
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. | |||||||||||||
| Advanced BGP Monitoring Protocol (BMP) Statistics Types | ||||||||||||||
|
RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines new statistics type to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs). | |||||||||||||
| BMP Loc-RIB: Peer address | ||||||||||||||
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. | |||||||||||||
| Procedures for Handling Liaison Statements to and from the IETF | ||||||||||||||
|
This document describes the procedures for generating and handling liaison statements between the IETF and other SDOs, so that the IETF can effectively collaborate with other organizations in the international standards community. | |||||||||||||
| On-Path Telemetry for Active Performance Measurements | ||||||||||||||
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. | |||||||||||||
| JMAP File Storage extension | ||||||||||||||
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. | |||||||||||||
| Asymmetric Manifest Based Integrity | ||||||||||||||
|
This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. | |||||||||||||
| Discovery Of Restconf Metadata for Source-specific multicast | ||||||||||||||
|
This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. | |||||||||||||
| Circuit Breaker Assisted Congestion Control | ||||||||||||||
|
This document specifies Circuit Breaker Assisted Congestion Control (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate metadata about multicast channels from senders to intermediate network nodes or receivers. The circuit breaker behavior is defined as a supplement to receiver driven congestion control systems, to preserve network health if misbehaving or malicious receiver applications subscribe to a volume of traffic that exceeds capacity policies or capability for a network or receiving device. | |||||||||||||
| NETCONF over QUIC | ||||||||||||||
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server | |||||||||||||
| YANG Groupings for QUIC clients and QUIC servers | ||||||||||||||
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server | |||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. | |||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. | |||||||||||||
| Multiple IPv4 - IPv6 mapped IPv6 address (M46A) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. | |||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. | |||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) | ||||||||||||||
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. | |||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. | |||||||||||||
| Multiple IPv4 - IPv6 address mapping translator (M46T) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. | |||||||||||||
| Multi-Stage Transparent Server Load Balancing | ||||||||||||||
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. | |||||||||||||
| Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. | |||||||||||||
| Extending ICMPv6 for SRv6-related Information Validation | ||||||||||||||
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. | |||||||||||||
| An EAT-based Key Attestation Token | ||||||||||||||
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. | |||||||||||||
| BGP Flow Specification for Source Address Validation | ||||||||||||||
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules. | |||||||||||||
| Kademlia-directed ID-based Routing Architecture (KIRA) | ||||||||||||||
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. | |||||||||||||
| Outer Header Translator | ||||||||||||||
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. | |||||||||||||
| A Profile for Autonomous System Relationship Authorization (ASRA) | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA. | |||||||||||||
| Provider Independent Addresses Aggregation | ||||||||||||||
|
This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future. | |||||||||||||
| AI based Network Management Agent(NMA): Concepts and Architecture | ||||||||||||||
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network or Intent-based Networking, and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. | |||||||||||||
| A YANG Data Model of Performance Management Streaming | ||||||||||||||
|
This document provides a YANG data model of performance management streaming from network equipment to clients. It defines PM measurement methods, event notifications, generic PM parameters and streaming subscriptions. Additionally, it includes a YANG module for PM interval capabilities discovery, enabling clients to understand supported sampling and measurement intervals before configuring PM measurements. | |||||||||||||
| A method for describing changes made to an email | ||||||||||||||
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. | |||||||||||||
| Computing Energy Consumption Path in Segment Routing Networks | ||||||||||||||
|
This document describes a method for computing energy consumption paths in Segment Routing (SR) networks, aiming to optimize network traffic routing for energy efficiency, including procedures for energy consumption data collection, path calculation, and issuance, as well as considerations for data plane implementation in both MPLS SR and SRv6 networks. | |||||||||||||
| A YANG Data Model for CMIS Access and Control | ||||||||||||||
|
This document provides a YANG data model to access to and control CMIS for managing pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside. CMIS has custom pages which enables to be defined by the module vendor for its own usage, and allows to extend the uses of the optics devices. | |||||||||||||
| OAuth 2.0 Refresh Token and Authorization Expiration | ||||||||||||||
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. | |||||||||||||
| BMP Sequence Number,Timestamp and Flags TLVs | ||||||||||||||
|
This document defines a Timestamp TLV that carries a timestamp describing one of multiple possible events related to the BMP message. It also defines a Sequence Number TLV which carries the sequence number of the BMP message for the current BMP session. Finally, this document defines an Extended Flags TLV that replaces the Flags field of the Per-Peer Header, allowing more flags to be allocated in BMP. | |||||||||||||
| Fast Notification for tunnel-based lossless RDMA transmission in WAN | ||||||||||||||
|
With the rapid development of Large Language Models (LLMs), many emerging AI services require lossless transmission of RDMA packets over tunnels in Wide Area Network(WAN). To meet the stringent performance demands of these services, WAN should support the real- time network state notification to ensure high throughput, low latency, and zero packet loss. The current reactive notification mechanisms are limited by responsiveness, coverage, and operational efficiency. Therefore, a faster and proactive notification mechanism is needed to enable more responsive Traffic Engineering (TE) and Load Balancing (LB). This draft describes typical scenarios for transmitting RDMA packets over WAN tunnels, specifies the fast notification framework to support key TE areas (e.g., congestion control, protection, and load balance), and defines the packet format for fast notification. | |||||||||||||
| Generative AI for Intent-Based Networking | ||||||||||||||
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. | |||||||||||||
| A YANG Data Model for Reporting Utilization Scores in ISAC | ||||||||||||||
|
This document defines a basic YANG data model to report sensing measurements utilization score (US) in Integrated Sensing and Communication (ISAC) systems. The score quantifies the resource impact of different sensing measurements, including compute, memory, storage, energy, and latency. The model supports per-measurement telemetry reporting. | |||||||||||||
| Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) | ||||||||||||||
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC8588. | |||||||||||||
| Testing Applications' IPv6 Support | ||||||||||||||
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-Stack (IPv4+IPv6), and IPv6-only scenarios, including "true IPv6-only" scenarios. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. | |||||||||||||
| 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. | |||||||||||||
| The 'donau' URI scheme for validation of Donau donation statements. | ||||||||||||||
|
This document defines the 'donau' Uniform Resource Identifier (URI) scheme for triggering interactions with a validator for Donau donation statements. This URI scheme allows applications to trigger interactions with a Donau validator. A Donau validator is typically run by a tax authority to validate tax records from citizens that made donations to a charity that supports the Donau protocol. The Donau validator will receive 'donau' URIs representing the sum of donations a taxpayer made to recognized charities over a year. Donors would submit 'donau' URLs (or QR codes with 'donau' URLs) to tax authorities to have their donations recognized by the tax authority as tax-deductable expenditures. The application logic to verify the validity of the donation is triggered by 'donau' URIs. The validator application would then typically confirm to the tax official the validity of the signature encoded in the URI and show the total amount donated as well as the taxpayer identification number and the year of the donation. Multiple URIs could be submitted per donor, and the application can correctly determine which submissions are cummulative and which ones are redundant. This specification only covers the syntax of the 'donau' URI scheme and excludes details on the protocol(s) that would allow taxpayers to donate to recognized charities to obtain these suitable signed donation statements. While a privacy-preserving protocol to obtain such statements exists within the context of the GNU Taler protocol suite, other protocols could be developed in the future and still yield compatible 'donau' URIs as the URI scheme is reasonably generic. | |||||||||||||
| CBOR Pointer: Selecting Elements of Concise Binary Object Representation (CBOR) Documents | ||||||||||||||
|
CBOR Pointer is a syntax to identify a single CBOR value from a CBOR document with an arbitrarily complex nested structure. It is analogous to JSON Pointer. | |||||||||||||
| Hardware-Rooted Attestation for Precision Time Protocol: Verifiable Residency and Proximity proofs | ||||||||||||||
|
This document defines an extension to Precision Time Protocol (PTP) that provides per-event cryptographic attestation using non-exportable asymmetric keys resident in TPMs or HSMs, and an optional PTP-in-HTTPS/MTLS encapsulation mode. When combined with freshness and multi-observer correlation, this provides defensible proof of proximity for timing events. PTP-in-HTTPS/MTLS adds end-to-end confidentiality for timing payloads across untrusted fabrics. NOTE: This note is a placeholder to show the correct structure that avoids the "setup generated" error (Line 53). All paragraphs inside a note must be separated by a blank line. *setup generated* | |||||||||||||
| BGP best path next-hop selection enhancements | ||||||||||||||
|
BGP [RFC4271] has originally been designed to carry IPv4 routing information over the Internet. IP routing being “hop-by-hop” in nature, [RFC4271] defines the NEXT_HOP attribute which purpose is to carry the address of the next router to send the IP packet to. In BGP, the next-hop may not be a directly connected router, hence, when evaluating paths, BGP needs to figure out if the next-hop is resolvable and, when needed, needs to figure out what is the internal cost to reach this next-hop. The incremental use of tunneling technologies to carry traffic between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6…) may violate the assumption that the address carried in the NEXT_HOP attribute is representative of the actual forwarding next-hop. These technologies decouple the BGP control-plane's view of the next-hop from the data- plane's actual forwarding endpoint. This document describes the problems that arise from this decoupling. These problems include sub-optimal path selection, incorrect resolvability tracking of the forwarding path leading to traffic drop or misrouting, and others. This document proposes some modification of BGP path selection procedures to accommodate these use cases. | |||||||||||||
| Agent Directory Service | ||||||||||||||
|
The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. | |||||||||||||
| Log More Routing Events in the BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The Route Event Logging (REL) message is defined in [I-D.ietf-grow-bmp-rel] and is used to report event-driven data to the BMP Server from the monitored routers. This document defines more event-driven data for BGP FlowSpec RFC8955 [RFC8956] and BGP SR Policies [I-D.ietf-idr-sr-policy-safi]. | |||||||||||||
| Model for distributed authorization policy sharing | ||||||||||||||
|
This document defines mechanisms and conventions for the representation and sharing of authorization policies in distributed and automated environments. It specifies the foundational elements required to express policies in a consistent, machine-readable, and interoperable manner, enabling fine-grained control and context-aware evaluation. The framework supports the complete policy lifecycle, including creation, validation, versioning, distribution, and decommissioning, with YANG serving as the canonical representation format. It also establishes the relationship between policy representation and the structure of tokens used in enforcement and authorization exchanges, ensuring coherent and dynamic policy evaluation across heterogeneous systems. | |||||||||||||
| CDNI Delivery Metadata | ||||||||||||||
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior for downstream CDN (dCDN) node selection, and request routing modes of traffic delegation. | |||||||||||||
| Geographic Attestation Results | ||||||||||||||
|
Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. This document is about encoding a variety of geographical conclusions in an Attestation Result. | |||||||||||||
| OAuth 2.0 Entity Profiles | ||||||||||||||
|
This specification introduces Entity Profiles as a mechanism to categorize OAuth 2.0 entities—clients and subjects—based on their operational context. Entity Profiles provide structured descriptors for the client initiating the OAuth flow and the subject represented in tokens. This document defines new JWT Claim names and metadata parameters for use in access tokens, ID tokens, token introspection responses, dynamic client registration, and Authorization Server metadata. | |||||||||||||
| 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. | |||||||||||||
| LISP Delegated Mappings | ||||||||||||||
|
The LISP protocol with its inherent decoupling of control-plane and data-plane, offers the flexibility to support modern networking paradigms. This document specifies how to use the LISP protocol to enable centralized onboarding and management of EIDs within a network from an external controller or orchestration system. Requirements Notation | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information | ||||||||||||||
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. Returning a single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Additionally, this document updates RFC 8231 to allow encoding of multiple Segment Lists in PCEP. | |||||||||||||
| Multicast Lessons Learned from Decades of Deployment Experience | ||||||||||||||
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. | |||||||||||||
| RATS Conceptual Messages Wrapper (CMW) | ||||||||||||||
|
The Conceptual Messages introduced by the RATS architecture (RFC9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. | |||||||||||||
| 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. | |||||||||||||
| A Comprehensive Errata for 'retransmission-allowed' XML Element | ||||||||||||||
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. | |||||||||||||
| YANG Data Model for SRv6 Base | ||||||||||||||
|
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). | |||||||||||||
| A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. | |||||||||||||
| 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]. | |||||||||||||
| Protocol Mapping for SDF | ||||||||||||||
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using specific IP and non-IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. | |||||||||||||
| Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks | ||||||||||||||
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. | |||||||||||||
| Meticulous Keyed ISAAC for BFD Optimized Authentication | ||||||||||||||
|
This document describes a BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate some BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the Up state. | |||||||||||||
| A Framework for Fast Reroute with Bit Index Explicit Replication (BIER-FRR) | ||||||||||||||
|
This document provides a framework for the development of Fast Reroute (FRR) mechanisms for Bit Index Explicit Replication forwarding (BIER-FRR). BIER-FRR can provide protection against link or BFR failure by invoking locally pre-determined repair paths that can react in the same time-scales as (unicast) FRR for MPLS or IP networks - "sub 50msec", and without the creation of additional per- path or per-flow state coordinated across multiple routers/LSR. BIER-FRR can be implemed locally within a router/LSR with minimal interoperability requirements against other router/LSR. It can therefore easily be introduced incrementally or selectively where needed. BIER-FRR implementing nodes only need to understand the routing topology of the network for calculation of repair paths and know what type of unicast encapsulation can be used to send ("tunnel") BIER packets to remote BFR. This document proposes and discusses different options for BIER forwardng (BIFT) extensions to support BIER-FRR. These are exemplary and non-normative. This document does not specify any standards or experiments but aims to support such efforts. | |||||||||||||
| JSCalendar: Converting from and to iCalendar | ||||||||||||||
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. | |||||||||||||
| JSCalendar: A JSON Representation of Calendar Data | ||||||||||||||
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. | |||||||||||||
| iCalendar Format Extensions for JSCalendar | ||||||||||||||
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). | |||||||||||||
| CBOR Extended Diagnostic Notation (EDN) | ||||||||||||||
|
This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -19 // includes the definition of the cri'' application- extension. cri'' // was previously defined in draft-ietf-core-href; however the latter // document overtook the present document in the approval process. // As the definition of cri'' is dependent on the present document // (and conversely has essentially no dependency on the technical // content of draft-ietf-core-href beyond its mere existence), the // text (including IANA considerations) has been moved here. -19 is // intended for use at the CBOR WG meeting at IETF 124. | |||||||||||||
| Deterministic Nonce-less Hybrid Public Key Encryption | ||||||||||||||
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. | |||||||||||||
| DTNMA Application Resource Identifier (ARI) | ||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. | |||||||||||||
| Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs) | ||||||||||||||
|
When Segment Routing (SR) is used for building Network Resource Partitions (NRPs), each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. This document describes how BGP-Link State (BGP-LS) with Multi-Topology (MT) can be used to distribute the information of SR-based NRPs to a network controller in a specific context where each NRP is associated with a separate logical topology identified by a Multi-Topology ID (MT-ID). This document sets out the targeted scenarios for the approach suggested, and presents the scalability limitations that arise. | |||||||||||||
| A YANG Data Model for ARP | ||||||||||||||
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. | |||||||||||||
| Algorithm Related IGP-Adjacency SID Advertisement | ||||||||||||||
|
The SR policy architecture defines the Prefix-SID algorithm, with an algorithm identifier included in the Prefix-SID advertisement. However, the Prefix-SID algorithm does not address scenarios where multiple algorithms share the same link resources. This document proposes adding the algorithm identifier in an Adjacency-SID advertisement. | |||||||||||||
| Proxying Bound UDP in HTTP | ||||||||||||||
|
The mechanism to proxy UDP in HTTP only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP proxying in HTTP that enables such use- cases. | |||||||||||||
| TCP ETS: Extensible Timestamp Options | ||||||||||||||
|
This document presents ETS: an Extensible TimeStamps option for TCP. It allows hosts to use microseconds as the unit for timestamps to improve the precision of timestamps, and extends the information provided in the [RFC7323] TCP Timestamps Option by including the receiver delay in the TSecr echoing, so that the receiver of the ACK is able to more accurately estimate the portion of the RTT that resulted from time traveling through the network. The ETS option format is extensible, so that future extensions can add further information without the overhead of extra TCP option kind and length fields. | |||||||||||||
| Compressed SID (CSID) for SRv6 SFC | ||||||||||||||
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. | |||||||||||||
| Distribution of Service Metadata in BGP-LS | ||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS. | |||||||||||||
| BGP SR Policy Extensions for Path Scheduling | ||||||||||||||
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a a network with time-variant characterics or requires high resources utilization efficiency, delivering the time-variant information associated with paths is necessary. This document proposes extensions to BGP SR Policy to deliver the schedule time information of candidate paths and segment lists. | |||||||||||||
| Merkle Tree Ladder (MTL) Mode Signatures | ||||||||||||||
|
This document provides an interoperable specification for Merkle tree ladder (MTL) mode, a technique for using an underlying signature scheme to authenticate an evolving series of messages. MTL mode can reduce the signature scheme's operational impact. Rather than signing messages individually, the MTL mode of operation signs structures called "Merkle tree ladders" that are derived from the messages to be authenticated. Individual messages are then authenticated relative to the ladder using a Merkle tree authentication path and the ladder is authenticated using the public key of the underlying signature scheme. The size and computational cost of the underlying signatures are thereby amortized across multiple messages, reducing the scheme's operational impact. The reduction can be particularly beneficial when MTL mode is applied to a post-quantum signature scheme that has a large signature size or computational cost. As an example, the document shows how to use MTL mode with ML-DSA as defined in FIPS204 and SLH-DSA as defined in FIPS205. Like other Merkle tree techniques, MTL mode's security is based only on cryptographic hash functions, so the mode is quantum- safe based on the quantum-resistance of its cryptographic hash functions. | |||||||||||||
| On-time Forwarding with Push-In First-Out (PIFO) queue | ||||||||||||||
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. | |||||||||||||
| Ways to convey the Ratchet Tree in Messaging Layer Security | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. | |||||||||||||
| OAM Requirements for Enhanced DetNet OAM | ||||||||||||||
|
This document describes the specific requirements of the Operations, Administration, and Maintenance (OAM) in Enhanced DetNet, and analyzes the gaps with existing OAM methods. The document also presents considerations for potential OAM solutions to address these requirements. | |||||||||||||
| Upper limit values for DNS | ||||||||||||||
|
DNS was designed to have as few hard upper limits as possible to allow for future extensibility. However, the lack of a clear upper limit leads to vulnerabilities, and several attack methods have been reported. This document collects upper limit values implemented by DNS software to avoid vulnerabilities. | |||||||||||||
| Semi-Private Messages in the Messaging Layer Security (MLS) Protocol | ||||||||||||||
|
This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. | |||||||||||||
| Extensions to IOAM Trace Option for Carrying Fixed-Size Data | ||||||||||||||
|
In situ Operations, Administration, and Maintenance (IOAM) Trace- Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the number of transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed- size data, the length of this kind of data is fixed once the selection of data fields processed by each IOAM-capable node is determined, and doesn't vary with the number of transited IOAM- capable nodes. | |||||||||||||
| Applicability of TVR YANG Data Models | ||||||||||||||
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include resource preservation networks, operating efficiency networks and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. | |||||||||||||
| In Situ Operations,Administration,and Maintenance (IOAM) Active Measurement for Multi-path | ||||||||||||||
|
Active measurements are typically used to collect the information of a specific path. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which promotes the information collection and topology restoration of a multi-path topology. It can help the operators to know the performance of network comprehensively and efficiently. | |||||||||||||
| Anomalous Packets Handling for DetNet | ||||||||||||||
|
In deterministic networking (DetNet), resource conflicts at flow aggregation nodes can lead to network anomalies. Existing data plane mechanisms for handling anomalous packets, such as simple discarding or treating them as Best-Effort (BE) flows, are insufficient. Consequently, the network performance can degrade to a level inferior to of traditional QoS approaches.Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an enhanced anomalous packet handling solution for DetNet. This solution specifies two policies: the packet squeezing policy and the packet degrading policy. These policies provide a flexible, enhanced mechanism applicable to various queuing mechanisms, ensuring the preferential scheduling and preservation of deterministic service traffic under anomalous conditions. | |||||||||||||
| Export of QUIC Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related and unencrypted information, which contained in QUIC Header that traffic is being forwarded along with. | |||||||||||||
| Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI. | |||||||||||||
| On-time Forwarding with Non-work Conserving Stateless Core Fair Queuing | ||||||||||||||
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [draft-ietf-detnet-dataplane-taxonomy-03]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded between ET and FT in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously compute ET and FT based on metadata received via packet headers. This mechanism is called non-work-preserving stateless fair queuing, which guarantees both E2E latency upper and lower bounds. | |||||||||||||
| PCE SR Policy Extensions for Path Scheduling | ||||||||||||||
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios. This document proposes extensions to PCE SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes. | |||||||||||||
| Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent. This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers. | |||||||||||||
| OAuth 2.0 App2App Browser-less Flow | ||||||||||||||
|
This document describes a protocol allowing a _Client App_ to obtain an OAuth grant from an _Authorization Server's Native App_ using the [App2App] pattern, providing *native* app navigation user-experience (no web browser used), despite both apps belonging to different trust domains. | |||||||||||||
| ICMP Error Handling in SRv6 based VPN Networks | ||||||||||||||
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). | |||||||||||||
| Priority-based Flow Control SID in SRv6 | ||||||||||||||
|
To address the issue of lossless transmission for cross-data center services, the PFC (Priority-based Flow Control) mechanism can be extended to wide-area networks (WANs) to solve packet loss caused by network congestion and the problem of backpressure signal transmission between WAN and RoCEv2 network in data centers. By leveraging SRv6 and slicing technologies, it is possible to effectively control the propagation range and path of PFC backpressure signals in wide-area networks, thereby avoiding issues such as deadlocks and the excessive propagation of congestion scope. PFC is a hop-by-hop mechanism. Given that most current WAN devices do not support PFC function, this document proposes defining a new type of SRv6 SID End.X.PFC to indicate the PFC-capable interface in the WAN network. | |||||||||||||
| HTTP Events Query | ||||||||||||||
|
Events Query is a minimal protocol built on top of HTTP that allows user agents to receive event notifications directly from any resource of interest. The Events Query Protocol (EQP) is predicated on the idea that the most intuitive source for event notifications is the resource itself. | |||||||||||||
| DART: Domain-Aware Routing Technology Protocol | ||||||||||||||
|
This document describes the Domain-Aware Routing Technology (DART), a novel addressing and routing protocol that introduces a Fully Qualified Domain Name (FQDN)-centric addressing model. DART operates over existing IP (IPv4 or IPv6) networks and employs the Domain Name System (DNS) as its control plane to map domain names to IP addresses. Within full compatibility with current IP infrastructure, DART extends the effective address space to infinity, enables seamless communication between IPv4 and IPv6 networks, and significantly improves Internet scalability and evolvability. By localizing the IP address space within each DNS domain, DART provides unlimited address reuse and constructs a more aggregated routing structure that alleviates global routing table pressure. The protocol transforms the paradigm from "IP-based addressing" to "domain-based addressing," laying the foundation for a unified, name- driven networking architecture. DART can be gradually deployed and upgraded without affecting existing communications, requiring hardware upgrades only for a small number of critical devices. A functional prototype of the DART system has been independently developed and deployed on Internet by the author. | |||||||||||||
| A SATP Core Binding for vLEI Identities | ||||||||||||||
|
The verifiable Legal Entity Identifier (vLEI) is a cryptographically verifiable extension of the LEI standard, designed to automate trust in organizational identity. Governed by the Global Legal Entity Identifier Foundation (GLEIF), the vLEI system uses Authentic Chained Data Containers (ACDCs), Self-Addressing Identifiers (SAIDs), and Key Event Receipt Infrastructure (KERI) to issue and verify credentials for legal entities and their authorized representatives. It enables secure, machine-readable identity assertions across financial, regulatory, and supply chain ecosystems, supporting role-based delegation and interoperability with decentralized trust frameworks. This specification defines vLEI for verifiable gateway operator identities and cryptographically links the gateway operator identity to the gateway identity. Thus SATP core lock assertions are cryptographically linked to gateway operator identities. | |||||||||||||
| DNSSEC Key Restore | ||||||||||||||
|
This document describes the issues surrounding the handling of DNSSEC private keys in a DNSSEC signer. It presents operational guidance in case a DNSSEC private key becoming inoperable. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/fobser/draft-fobser-dnsop-dnssec-keyrecovery. | |||||||||||||
| Using the Internet Key Exchange Protocol Version 2 (IKEv2) for PSP Key Management | ||||||||||||||
|
This document specifies how the Internet Key Exchange Version 2 (IKEv2) protocol can be used for supplying keys for the PSP Security Protocol (PSP). | |||||||||||||
| A more efficient FramedContentTBS structure in Messsaging Layer Security (MLS) | ||||||||||||||
|
Most MLS signatures are signed over the relatively large GroupContext structure. This document defines a way to safely sign using a pre- hashed version of the GroupContext structure for better efficiency. | |||||||||||||
| Brokered Agent Network for DNS AI Discovery | ||||||||||||||
|
The emerging field of agent-to-agent protocol standards introduces new requirements in order to facilitate discovery, trust signaling, session negotiation and communication. This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as _Brokered Agent Network for DNS AI Discovery_ (BANDAID), defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. BANDAID introduces a leaf zone convention (e.g., _agents.example.com) containing Service Binding (SVCB) records (e.g., chat._agents.example.com) that encode application-specific metadata. These records enable agents to retrieve operational parameters prior to initiating a session, supporting both targeted lookups and capability-based discovery. The approach leverages existing DNS infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and DANE, to provide integrity, authenticity, and automation without requiring human intervention. Lastly, the draft for Domain Control Validation (DCV) proposes a best current practice to prove an agent is authorized to act on behalf of a domain. _This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values._ | |||||||||||||
| An Overview of Messaging Systems and Their Applicability to Agentic AI | ||||||||||||||
|
Agentic AI systems require messaging infrastructure that supports real-time collaboration, high-volume streaming, and dynamic group coordination across distributed networks. Traditional protocols like AMQP, MQTT, and NATS address some requirements but fall short on security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise protection and quantum-safe encryption essential for autonomous agents handling sensitive data. This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical for GenAI agent systems: streaming performance, delivery guarantees, security models, and operational complexity. We examine how each protocol's design decisions impact agentic AI deployments, from lightweight edge computing scenarios to large-scale multi- organizational collaborations. AGNTCY SLIM emerges as a purpose-built solution, integrating Message Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540] to provide quantum-safe end-to-end encryption, efficient streaming, and OAuth-based authentication [RFC6749]. Unlike transport-layer security approaches, SLIM's MLS implementation ensures secure communication even through untrusted intermediaries while supporting dynamic group membership changes essential for collaborative AI agents. | |||||||||||||
| Secure Low-Latency Interactive Messaging (SLIM) | ||||||||||||||
|
This document specifies the Secure Low-Latency Interactive Real-Time Messaging (SLIM), a protocol designed to support real-time interactive AI applications at scale. SLIM leverages gRPC and adds publish-subscribe capabilities to enable efficient many-to-many communication patterns between AI agentic applications (AI models, tools and data). The protocol provides mechanisms for connection management, stream multiplexing, and flow control while maintaining compatibility with existing gRPC deployments. | |||||||||||||
| Post-Quantum Cryptography Strategy for DNSSEC | ||||||||||||||
|
This document proposes a post-quantum cryptography (PQC) strategy for Domain Name System Security (DNSSEC) that includes two types of algorithms: one or more conservatively designed algorithms that are unlikely ever to need to be replaced, and one or more low-impact drop-in algorithms that are used the same way as a traditional signature algorithm. The conservatively designed algorithms can be used in a mode of operation that mitigates the operational impact of a large signature size. The combination provides both the routine performance of the low-impact algorithm and a resilient fallback to the conservatively designed choice. The draft outlines the strategy, provides recommendations for future testing and deployment, and highlights operational considerations in adopting PQC for DNSSEC. | |||||||||||||
| KEM-based Authentication for EDHOC | ||||||||||||||
|
This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. | |||||||||||||
| KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios | ||||||||||||||
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. | |||||||||||||
| SCIM Agents and Agentic Applications Extension | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) specification [RFC7643] provides schemas that represent common identity information about users and groups, as well as a protocol for communicating that information between systems. The systems that tend to implement SCIM clients and servers are identity providers, and service providers. These are the same systems that are now need to manage agents and agentic applications across domains. This document describes a SCIM 2.0 extension for agents and agentic applications, which includes extensions to the core User and Group objects, and new resource types and schemas for agentic constructs. This extension is intended to provide greater interoperability between Identity providers, agentic applications, agents and their clients while reducing the responsibilities assumed by the every growing list of new protocols for agents. | |||||||||||||
| A PCE-based Control Plane Framework for Multi-Domain Deterministic Networking (DetNet) | ||||||||||||||
|
Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency over a path or network. As DetNet deployments expand, they will inevitably need to span multiple domains that may be under separate administrative or technological control. This creates a need for a control plane solution that can establish and maintain end-to-end DetNet services across these domain boundaries. This document defines a framework for a Path Computation Element (PCE)-based control plane for multi-domain DetNet. It first establishes a working definition of a "DetNet Domain" for the purpose of path computation and control. It then describes two high-level architectural approaches for inter-domain path computation and resource reservation: a Hierarchical PCE model and a peer-to-peer PCE "stitching" model. This framework provides the foundation for more specific work on multi-domain DetNet solutions. | |||||||||||||
| Symbol Transport Protocol (STP) | ||||||||||||||
|
The Symbol Transport Protocol (STP) proposes a novel data representation and transport method that replaces raw byte sequences with symbol-based pattern acceleration. By identifying and transmitting recurring data structures as symbols instead of explicit bytes, STP seeks to reduce bandwidth, improve latency, and enhance efficiency across structured and semi-structured data domains. | |||||||||||||
| HTTP/1.1 Request Smuggling Defense using Cryptographic Message Binding | ||||||||||||||
|
HTTP/1.1 Message Binding adds new hop-by-hop header fields that are cryptographically bound to requests and responses. The keys used are negotiated out-of-band from the HTTP datastream (such as via TLS Exporters). These header fields allow endpoints to detect and mitigate desynchronization attacks, such as HTTP Request Smuggling, that exist due to datastream handling differences. | |||||||||||||
| Reusable templates and checksum offload for CONNECT-IP | ||||||||||||||
|
This document defines extensions to the CONNECT-IP protocol (RFC 9484) that improve the efficiency of datagram transmission by introducing reusable templates and checksum offload capabilities. Reusable templates allow endpoints to associate Context Identifiers with static portions of packet headers, enabling datagrams to omit repeated byte sequences while remaining self-contained and stateless on the wire. Checksum offload enables endpoints to delegate computation of transport-layer checksums to the receiver by signaling the relevant offsets within the reconstructed packet. These optimisations reduce per-packet overhead, processing cost, and effectively increase the usable maximum transmission unit (MTU) when CONNECT-IP datagrams are encapsulated in QUIC DATAGRAM frames. | |||||||||||||
| Ubiquitous Access Collaboration Requirements for AI Agent Protocols | ||||||||||||||
|
This document focuses on the ubiquitous access collaboration scenarios, explores the requirements for AI agent communication protocols. | |||||||||||||
| Carrying location objects with uncertainty in RADIUS | ||||||||||||||
|
This document describes a new location profile for use with the RADIUS Location-Data Attribute. The new profile is used to carry a geospatial location profile that includes location uncertainty. | |||||||||||||
| Network Time Protocol Version 5 | ||||||||||||||
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. | |||||||||||||
| IP Flow Information Export (IPFIX) Alternate-Marking Information Elements | ||||||||||||||
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. | |||||||||||||
| EAT Measured Component | ||||||||||||||
|
The term "measured component" refers to an object within the attester's target environment whose state can be inspected and, typically, digested. A digest is computed through a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. | |||||||||||||
| SCIM Roles and Entitlements Extension | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) protocol schema, defined in RFC [RFC7643] defines the complex core schema attributes "roles" and "entitlements". For both of these concepts, frequently only a predetermined set of values are accepted by a SCIM service provider. The values that are accepted may vary per customer or tenant based on customizable configuration in the service provider's application or based on other criteria such as what services have been purchased or resources associated with entitlements. This document defines an extension to the SCIM 2.0 standard to allow SCIM service providers to represent available data pertaining to SCIM resources, roles and entitlements so that SCIM clients can consume this information and provide easier management of SCIM resources, role and entitlement assignments. | |||||||||||||
| A recommendation for filtering address records in stub resolvers | ||||||||||||||
|
Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. | |||||||||||||
| The JSON vCon - Contact Center Extension | ||||||||||||||
|
A vCon is container for data and information relating to a human conversation. This document defines an extension for the JSON vCon schema in support of call, support or contact center application of the vCon conversational data exchange format. | |||||||||||||
| WIMSE Workload-to-Workload Authentication | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. | |||||||||||||
| RTP Payload Format for Visual Volumetric Video-based Coding (V3C) | ||||||||||||||
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. | |||||||||||||
| Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media | ||||||||||||||
|
This document describes RTCP messages and RTP header extensions to enable partial access and support viewport- and region-of-interest- dependent delivery of visual volumetric media such as visual volumetric video-based coding (V3C). Partial access refers to the ability to access retrieve or deliver only a subset of the media content. The RTCP messages and RTP header extensions described in this document are useful for XR services which transport coded visual volumetric content, such as point clouds. | |||||||||||||
| Packed CBOR | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -17 contains a number of editorial improvements, it is // intended for a brief discussion at the 2025-10-15 CBOR WG interim. // The wording of the present revision continues to make use of the // tunables A/B/C to be set to specific numbers before completing the // Packed CBOR specification; not all the examples may fully align // yet. | |||||||||||||
| A YANG Data Model for Ethernet TE Topology | ||||||||||||||
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. | |||||||||||||
| A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) | ||||||||||||||
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | |||||||||||||
| Clarifications on CDS/CDNSKEY and CSYNC Consistency | ||||||||||||||
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent- side Resource Record Sets (RRsets) of the delegation. This document specifies that when performing such queries, parent- side entities has to ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. This document updates RFC 7344 and RFC 7477. | |||||||||||||
| Bundle Protocol Security (BPSec) COSE Context | ||||||||||||||
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. | |||||||||||||
| Bundle Protocol Endpoint ID Patterns | ||||||||||||||
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. | |||||||||||||
| Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | ||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. | |||||||||||||
| A YANG Data Model for BGP Communities | ||||||||||||||
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. Two YANG modules are defined in this document. The first is designed for stand-alone usage. The second is used to augment the "ietf-bgp" YANG module[I-D.ietf-idr-bgp-model] with BGP community annotations. | |||||||||||||
| The Idempotency-Key HTTP Header Field | ||||||||||||||
|
The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. | |||||||||||||
| BGP SR Policy Extensions to Enable IFIT | ||||||||||||||
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. | |||||||||||||
| BGP for BIER-TE Path | ||||||||||||||
|
This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path. | |||||||||||||
| Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. | |||||||||||||
| Composite ML-KEM for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. | |||||||||||||
| An Update of Operators Requirements on Network Management Protocols and Modelling | ||||||||||||||
|
The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. | |||||||||||||
| A YANG Data Model for Client-layer Tunnel | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. | |||||||||||||
| IKEv2 Support for Child SA PFS Policy Information | ||||||||||||||
|
This document defines an extension for the Internet Key Exchange Protocol Version 2 (IKEv2) to support negotiation at the time of initial Child Security Association (SA) establishing of Key Exchange (KE) method that could be used in subsequent rekeys of this SA. | |||||||||||||
| IPv6 Addresses for Ad Hoc Networks | ||||||||||||||
|
Ad Hoc networks present an IPv6 addressing challenge due to the undetermined neighborhood properties of their interfaces. IPv6 nodes assign IPv6 addresses to their Ad Hoc networks that must be locally unique. IPv6 nodes must therefore be able to assign topology- independent addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type that nodes can autonomously assign for use over Ad-Hoc networks. | |||||||||||||
| Source Prefix Advertisement for Intra-domain SAVNET | ||||||||||||||
|
This document proposes a new mechanism for intra-domain source address validation (SAV), called Source Prefix Advertisement (SPA) for Intra-domain SAVNET (referred to as Intra-domain SPA). The mechanism enables intra-domain routers to automatically generate more accurate SAV rules by leveraging both routing information and SAV- specific information, including Source Entity Identifiers (SEIs) and Hidden Prefix Registration (HPR). Intra-domain SPA addresses scenarios such as asymmetric routing and hidden prefixes, improving the precision and reliability of source address validation. | |||||||||||||
| Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol | ||||||||||||||
|
This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements. | |||||||||||||
| BGP SR Policy Extensions for Performance-Aware Path Selection | ||||||||||||||
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute [RFC9012]. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in [RFC4271], modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection | |||||||||||||
| The agent:// Protocol -- A URI-Based Framework for Interoperable Agents | ||||||||||||||
|
This document defines the agent:// protocol, a URI template-based framework as described in RFC 6570 for addressing, invoking, and interoperating with autonomous and semi-autonomous software agents. It introduces a layered architecture that supports minimal implementations (addressing and transport) and extensible features (capability discovery, contracts, orchestration). The protocol aims to foster interoperability among agents across ecosystems, platforms, and modalities, enabling composable and collaborative intelligent systems. | |||||||||||||
| AS2 Specification Modernization | ||||||||||||||
|
This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. | |||||||||||||
| Proxy for Congestion Notification | ||||||||||||||
|
This document describes the necessity and feasibility to introduce a proxy network node between the congested network node and the traffic sender. The proxy network node is used to translate the congestion notification. The congested network node sends the congestion notification to the proxy network node in a format defined in this document, and then the proxy network node translates the received congestion notification to a format known by the traffic sender and resends the translated congestion notification to the traffic sender. | |||||||||||||
| RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. | |||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Verified Contact Information | ||||||||||||||
|
This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. | |||||||||||||
| The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. | |||||||||||||
| A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) | ||||||||||||||
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a DER-encoded data interchange format which can be used to represent various aspects of the state of a validated cache at a particular point in time. The CCR profile is a compact and versatile format well-suited for a diverse set of applications such as audit trail keeping, validated payload dissemination, and analytics pipelines. | |||||||||||||
| HTTP-Based AI Agent Discovery and Invocation Protocol | ||||||||||||||
|
This document proposes a standardized protocol for *discovery and invocation of AI agents* over HTTP. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a semantic search mechanism to discover and match agents based on capabilities, and a unified RESTful invocation interface for calling those agents. The goal is to enable cross-platform interoperability among AI agents by providing a *“discover and match”* mechanism and a *unified invocation entry point* via standard HTTP. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms. | |||||||||||||
| SRv6 Policy Selector | ||||||||||||||
|
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes a policy selection mechanism among the candidate SRv6 Policies based on network quality in IPv6 environments. | |||||||||||||
| Origin-Bound Cookies | ||||||||||||||
|
This draft introduces Origin-Bound Cookies which updates [COOKIES] aiming to make cookies more secure by default through binding cookies by port and scheme. | |||||||||||||
| PCE LSP validation Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). A Stateful PCE RFC8231 can instantiate LSPs on a PCC. In some cases, the PCC shall perform additional validations and/or actions. If some validations or actions fail, the LSP will not be created and established or updated. This document specifies PCEP extensions to handle this situation gracefully in case the problem can be resolved by some network changes (freeing up resources, restoring or changing the network, and so on). This draft defines common usage of the new flag and known use cases for using this flag. Each draft relevant to LSP creation can add a corresponding bit to the use case list. | |||||||||||||
| AI Agent Discovery (AID) Problem Statement | ||||||||||||||
|
With the deployment of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document presents requirements and considerations for agent-to-agent discovery. | |||||||||||||
| QUIC New Server Preferred Address | ||||||||||||||
|
This document specifies an extension to QUIC to allow a server to request a migration to a new preferred address. | |||||||||||||
| Constraining RPKI Trust Anchors | ||||||||||||||
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations. | |||||||||||||
| Provider Interface SAV for Customer Cone Sources | ||||||||||||||
|
Current source address validation (SAV) on AS's provider interfaces primarily relies on loose uRPF, which can protect against IP spoofing based on unannounced internet prefixes but lacks the ability to defend against spoofing based on valid internet prefixes. Furthermore, if a default route exists, this protection mechanism becomes ineffective. Based on the traffic flow characteristics between the ASes in a customer cone, this document describes a general solution architecture -- provider interface SAV for customer cone source spoofing (PI-SAV for CC). This mechanism can be applied on the provider interfaces of an AS to prevent spoofing traffic with the customer cone source addresses from flowing into the local AS and its customer cone. Specially, this mechanism offers protection against reflective amplification DDoS attacks that leverage local servers to target victims within the customer cone. | |||||||||||||
| Strengthening DNS Query Aggregation against ECS-based Attacks | ||||||||||||||
|
The DNS query aggregation mechanism is a critical defense against DNS cache poisoning attacks that exploit the "Birthday Paradox". However, recent research has revealed that flawed implementations of the EDNS Client Subnet (ECS) option, as specified in RFC 7871, can be exploited to bypass this defense. This allows attackers to force a resolver to issue multiple simultaneous queries for the same domain name by crafting queries with different ECS options. This vulnerability revives the classic DNS Birthday Attack, posing a significant threat to DNS resolvers and the clients they serve. This document specifies a stricter and more coherent processing model for the ECS option in DNS resolvers. It introduces a mechanism for resolvers to track the ECS support state of authoritative nameservers and mandates query aggregation for zones determined to not support ECS. These changes are designed to close the identified vulnerability and restore the effectiveness of query aggregation as a defense mechanism. | |||||||||||||
| PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters | ||||||||||||||
|
This document defines PQ/T composite schemes based on ML-KEM and ML- DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol. | |||||||||||||
| Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow such extensions. | |||||||||||||
| PIM Flooding Mechanism and Source Discovery Enhancements | ||||||||||||||
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used to provide various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM deployments. | |||||||||||||
| The Internet Standards Process | ||||||||||||||
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. | |||||||||||||
| IETF Working Group Guidelines and Procedures | ||||||||||||||
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. | |||||||||||||
| The JSON format for vCon - Conversation Data Container | ||||||||||||||
|
vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. | |||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | ||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | |||||||||||||
| Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer | ||||||||||||||
|
This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network. | |||||||||||||
| Constrained Application Protocol (CoAP) over Bundle Protocol (BP) | ||||||||||||||
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. | |||||||||||||
| ML-DSA for JOSE and COSE | ||||||||||||||
|
This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. | |||||||||||||
| A Border Gateway Protocol 4 (BGP-4) | ||||||||||||||
|
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271. | |||||||||||||
| Communicating Proxy Configurations in Provisioning Domains | ||||||||||||||
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. 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/tfpauly/privacy-proxy. | |||||||||||||
| A Base YANG Data Model for Network Inventory | ||||||||||||||
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. | |||||||||||||
| Interoperable Email Addresses for SMTPUTF8 | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding elements that harm human-to-human interoperation. This is one of a pair of documents: this contains recommendations for what addresses humans should use, such that address provisioning systems can restrain themselves to addresses that email valdidators accept. (This set can also be described in other ways, including "simple to cut-and-paste" and "understandable by some community".) Its companion defines simpler rules, accepts more addresses, and is intended for software like MTAs. | |||||||||||||
| SMTPUTF8 address syntax | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: This is simple to implement, contains only globally viable rules and is intended to be usable for software such an MTA. Its companion defines has more complex rules, takes regional usage into account and aims to allow only addresses that are readable and cut-and-pastable in some community. | |||||||||||||
| DNS and PREF64 Configuration for Proxying IP in HTTP | ||||||||||||||
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information. This document defines extensions that convey DNS and PREF64 configuration using HTTP capsules. This mechanism supports encrypted DNS transports and can be used to inform peers about network translation prefixes for IPv6/IPv4 synthesis. | |||||||||||||
| UDP-based Transport for Configured Subscriptions | ||||||||||||||
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. | |||||||||||||
| Supplement of BGP-LS Distribution for SR Policies and State | ||||||||||||||
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags and a new sub-TLV are introduced in the SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. | |||||||||||||
| One Administrative Domain using BGP | ||||||||||||||
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). | |||||||||||||
| Flow Aggregation for Enhanced DetNet | ||||||||||||||
|
[I-D.ietf-detnet-scaling-requirements] proposed the data plane requirements in scaling networks. This document describes the additional requirements for flow aggregation in enhanced DetNet and provides the enhancement consideration. It also discusses how the flow aggregation could be realized in a 5GS logical DetNet node participating in enhanced DetNet. | |||||||||||||
| ICMP extension to include underlay information | ||||||||||||||
|
Network operators managing overlay networks require visibility into underlay network hops during traceroute operations from overlay endpoints. This document defines an ICMP extension object, the Underlay Information Object (UIO), which allows underlay head-end nodes to encapsulate underlay error information within ICMP error messages. This mechanism provides overlay operators with crucial visibility into underlay network paths for troubleshooting. | |||||||||||||
| BGP Flowspec Redirects to SR Policy | ||||||||||||||
|
BGP Flowspec, an extension of BGP, facilitates the distribution of traffic flow specification rules and supports steering traffic into Segment Routing (SR) Policies. However, current approaches that leverage Flowspec to direct traffic toward a SR Policy exhibit certain limitations (for detailed analysis, refer to Section 1). Using the Community Container attribute, this document defines two new standard actions for the BGP Flowspec Version 2 (FSv2) protocol: the Redirect to SR Policy Action and the SRv6 SID Action. The former enables traffic to be directed to a designated SR Policy, while the latter supports encapsulating an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action may be used either independently or in conjunction with the SRv6 SID Action, depending on the specific application scenario. Additionally, the SRv6 SID Action can be combined with other actions defined in FSv2, such as the Redirect to IPv6 Action. | |||||||||||||
| CBOR : : Core - CBOR Cross Platform Profile | ||||||||||||||
|
This document defines CBOR::Core, a platform profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. To foster interoperability, deterministic encoding is mandated. Furthermore, the document outlines how deterministic encoding combined with enhanced CBOR tools, enable cryptographic methods like signing and hashing, to optionally use "raw" (non-wrapped) CBOR data as input. This document mainly targets CBOR tool developers. | |||||||||||||
| Benchmarking Methodology for Computing-aware Traffic Steering | ||||||||||||||
|
Computing-aware traffic steering(CATS) is a traffic engineering approach based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. | |||||||||||||
| IoT DNS Security and Privacy Guidelines | ||||||||||||||
|
This document outlines best current practices for Internet of Things (IoT) device providers regarding the implementation of DNS stub resolvers, with the aim of mitigating security threats, enhancing privacy, and resolving operational challenges. It also provides guidelines for network operators on mitigating the risks identified in this draft. | |||||||||||||
| SRv6 Anycast VPN Service | ||||||||||||||
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines anycast flavor for SRv6 Service SIDs carried in BGP messages. | |||||||||||||
| Guidance for Migration to Composite,Dual,or PQC Authentication | ||||||||||||||
|
This document provides guidance for migration from traditional digital signature algorithms to post-quantum cryptographic (PQC) signature algorithms. It compares three models under discussion in the IETF for PKI-based protocols: composite certificates, dual certificates, and PQC certificates. The goal is to help operators and engineers working on cryptographic libraries, network security, and PKI/key management infrastructure select an approach that balances interoperability, security, and operational efficiency during the transition to post-quantum authentication. | |||||||||||||
| New Content Types for Messaging Layer Security (MLS) | ||||||||||||||
|
This Messaging Layer Security (MLS) extensions adds two new variations of the application content type, each with a separate key ratchet. It also creates an MLS capability to negotiate use of the new types, and an IANA registry to register additional content types. | |||||||||||||
| GhostLock - A Hybrid Post-Quantum Encryption Protocol Combining Classical and Lattice-Based Cryptography | ||||||||||||||
|
The advent of quantum computing threatens the security of classical cryptographic primitives, making it essential to design hybrid schemes that remain secure against both classical and quantum adversaries. This document specifies GhostLock, a file-level hybrid encryption protocol that combines classical elliptic-curve cryptography (X25519, Ed25519) with post-quantum lattice-based mechanisms (Kyber768), integrated under a modern AEAD cipher (ChaCha20-Poly1305). The protocol defines a portable encrypted container format (.glock) providing confidentiality, integrity, and authenticity beyond the lifetime of current cryptosystems. | |||||||||||||
| BGP Next Hop Dependent Characteristics Attribute | ||||||||||||||
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. | |||||||||||||
| BGP Entropy Label Characteristic | ||||||||||||||
|
The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. | |||||||||||||
| Separating DPoP Bindings for Access and Refresh Tokens | ||||||||||||||
|
This document defines an extension to OAuth 2.0 Demonstrating Proof- of-Possession at the application level (DPoP, RFC 9449) that allows refresh tokens to be bound to a different proof-of-possession key than access tokens. In the existing specification, a single DPoP proof is used to bind both tokens to the same key material. However, in many deployments, refresh tokens and access tokens are stored and managed in different security contexts. To support this operational separation, this document introduces a new HTTP header field, DPoP- RT, and corresponding DPoP-RT-Nonce mechanism, enabling independent proof-of-possession for refresh token use while preserving compatibility with existing DPoP-bound access tokens. | |||||||||||||
| BGP SR Policy Extensions for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists. The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. This document proposes the BGP SR policy extensions for distributing CATS services. | |||||||||||||
| ACK Frequency Adjustment Strategy Based on Congestion Control Algorithms | ||||||||||||||
|
TCP Delayed ACK is a widely deployed mechanism that can effectively reduce protocol overhead in many scenarios. The TARR option has been defined, which allows a sender to request a specific ACK frequency from a receiver. However, there is no clear method for adjusting the ACK frequency during data transmission over a TCP connection. This document provides a method for adjusting the ACK frequency by considering the different phases of congestion control algorithms. | |||||||||||||
| Post-Quantum Cryptography in OpenPGP | ||||||||||||||
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. | |||||||||||||
| A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) | ||||||||||||||
|
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). | |||||||||||||
| PCEP extensions for Distribution of Link-State and TE Information | ||||||||||||||
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. | |||||||||||||
| RDAP Extensions | ||||||||||||||
|
This document describes and clarifies the usage of extensions in RDAP. | |||||||||||||
| RIFT Key/Value TIE Structure and Processing | ||||||||||||||
|
The RIFT (Routing in Fat Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. | |||||||||||||
| Distribute SRv6 Locator by DHCP | ||||||||||||||
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment IDs are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through DHCPv6. | |||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things | ||||||||||||||
|
The Semantic Definition Format (SDF) is concerned with Things, namely physical objects that are available for interaction over a network. SDF is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. | |||||||||||||
| CBOR Common Deterministic Encoding (CDE) | ||||||||||||||
|
CBOR (STD 94, RFC 8949) defines the concept of "Deterministically Encoded CBOR" in its Section 4.2, determining one specific way to encode each particular CBOR value. This definition is instantiated by "core requirements", providing some flexibility for application specific decisions; this makes it harder than necessary to offer Deterministic Encoding as a selectable feature of generic CBOR encoders. The present specification documents the Best Current Practice for CBOR _Common Deterministic Encoding_ (CDE), which can be shared by a large set of applications with potentially diverging detailed application requirements. The document also discusses the desire for partial implementations, which can be another reason for constraining CBOR encoders, and singles out the encoding constraint "definite-length-only" as a likely constraint to be used in application protocol and media type definitions. This specification updates RFC 8949 in that it provides clarifications and definitions of additional terms as well as more examples and explanatory text; it does not make technical changes to RFC 8949. // This revision -13 merges all active pull requests in preparation // for the 2025-cbor-17 interim on 2025-10-15. | |||||||||||||
| Domain Control Validation using DNS | ||||||||||||||
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. | |||||||||||||
| SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS | ||||||||||||||
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. | |||||||||||||
| Segment Routing Path MTU in BGP | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. | |||||||||||||
| BGP SR Policy Extensions for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. | |||||||||||||
| Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) | ||||||||||||||
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. | |||||||||||||
| IETF Community Moderation | ||||||||||||||
|
The IETF community will treat people with kindness and grace, but not endless patience. This memo establishes a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of guidelines and facilitate their consistent implementation with chairs and administrators. | |||||||||||||
| An IPv4 Flowlabel Option | ||||||||||||||
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. | |||||||||||||
| Deadline Based Deterministic Forwarding | ||||||||||||||
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. | |||||||||||||
| IGP Color-Aware Shortcut | ||||||||||||||
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document specifies the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. | |||||||||||||
| Computing-Aware Traffic Steering (CATS) Using Segment Routing | ||||||||||||||
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifiers and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. | |||||||||||||
| Hybrid IANA Registration Policy | ||||||||||||||
|
The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies. | |||||||||||||
| CATS BGP Extension | ||||||||||||||
|
CATS (Computing-Aware Traffic Steering) is a traffic engineering approach that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a service contact instance. This document defines the control plane BGP extension for CATS (Computing-Aware Traffic Steering). | |||||||||||||
| Problem Statement with Aggregate Header Limit for IPv6 | ||||||||||||||
|
This document first proposes the concept of "Aggregate header limit for IPv6"(IPv6-AHL) to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. | |||||||||||||
| Best Practices for Persistent References in DNS | ||||||||||||||
|
This document details some best practices for Application Service Providers who allow associations between a global DNS domain name and use case specific references using DNSSEC to provide a globally consistent, cryptographically verifiable association. Such a mechanism is needed when nonce-based domain control validation is not practical, such as use cases where each participant wants to confirm the association independently. As such, no single Application Service Provider exists to provide and validate a nonce to prove domain control that would satisfy other participating Application Service Providers. | |||||||||||||
| CBOR Serialization and Determinism | ||||||||||||||
|
This document defines two CBOR serializations: "ordinary serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the full, variable set of serialization options defined in [STD94]. Together, these three form a complete set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. | |||||||||||||
| Evidence Package Format Specification: Storing Evidence from Software Testing | ||||||||||||||
|
Taking evidence is a key part of any robust software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. This work is not a standard and does not enjoy community consensus. | |||||||||||||
| Tunnel Extensible Authentication Protocol (TEAP) Version 2 | ||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues in TEAPv1 which was defined in [I-D.ietf-emu-rfc7170bis]. | |||||||||||||
| Proquints: Readable,Spellable,and Pronounceable Identifiers | ||||||||||||||
|
This document specifies "proquints" (PRO-nounceable QUINT-uplets), a human-friendly encoding that maps binary data to pronounceable identifiers using fixed consonant-vowel patterns. The concept was originally described by Daniel Shawcross Wilkerson in 2009. This document formalizes the format for archival and reference. | |||||||||||||
| Adaptive Layered Voice Container (ALVC) for Constrained Networks | ||||||||||||||
|
This document specifies the Adaptive Layered Voice Container (ALVC), a codec-agnostic framing and metadata container that enables progressive voice delivery in constrained and lossy networks. ALVC defines a Base layer that is intelligible on its own at sub-kilobit rates, and optional Enhancement layers that improve quality when additional capacity is available. The container supports store-and- forward operation, progressive enhancement, unequal error protection signaling, and receiver behavior for seamless splice-and-improve playback. ALVC does not define a new speech coding algorithm; it multiplexes existing voice coders within a layered container. | |||||||||||||
| Carrying ALVC over LPWAN using SCHC Fragmentation and Priorities | ||||||||||||||
|
This document specifies how to carry the Adaptive Layered Voice Container (ALVC) over Low-Power Wide-Area Networks (LPWAN) using Static Context Header Compression (SCHC). ALVC is codec-agnostic and progressive: a sub-kilobit Base stream provides immediate intelligibility while optional Enhancement streams improve quality when bandwidth allows. This document defines SCHC rules, fragmentation parameters, and unequal error protection (UEP) so that Base traffic is delivered promptly and reliably, while Enhancements are sent opportunistically. The specification targets constrained networks with small payloads, duty-cycle limits, and loss, and does not define a new speech coding bitstream. A companion Internet-Draft describes the codec-agnostic ALVC container, and SCHC is specified in RFC 8724. | |||||||||||||
| DNS Backend Serial Zone Version Option | ||||||||||||||
|
The DNS Backend Serial Zone Version Opion is a way to get information about the version of a DNS zone in the backend. For example when a DNSSEC signer for a zone generates a new SOA serial, because it has created new RRSIG records, the original data has not changed, but this is not visible to anyone looking at the zone via DNS. This document will make it possible to show the zone information which is the source of the presented data. | |||||||||||||
| DNS Policy Redirection Mechanisms: RPZ-EDE Enhancement and URI-R Redirection Record | ||||||||||||||
|
This document defines two complementary mechanisms to improve user experience and policy transparency in DNS-based filtering. The first mechanism enhances Response Policy Zone (RPZ) operation through Extended DNS Error (EDE) signaling. The second introduces a new URI-REDIRECT (URI-R) Resource Record to support secure, application-level redirection for both HTTP and HTTPS traffic. Each mechanism can operate independently or together, enabling network operators and resolvers to provide safer, TLS-compliant redirection for policy-enforced domains. | |||||||||||||
| Best Current Practice for ROA Issuance Restrictions in RPKI | ||||||||||||||
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It mandates that a parent Certification Authority (CA) MUST NOT issue ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are required to enforce this restriction by rejecting or flagging invalid ROAs issued outside of resource allocations. | |||||||||||||
| Agentic Dispute Protocol | ||||||||||||||
|
This document specifies the Agentic Dispute Protocol (ADP), a standardized framework for autonomous agents and AI systems to file, process, and resolve disputes through structured, automated processes. The protocol defines message formats, transport mechanisms, evidence submission standards, and cryptographic proof requirements for internet-native dispute resolution. ADP is designed to handle disputes arising from AI agent interactions, service level agreement breaches, and automated contract enforcement, providing deterministic, auditable, and legally enforceable outcomes. ADP includes chain of custody tracking, dual-format award specifications (JSON and PDF), arbitrator discovery mechanisms, and support for multiple resolution frameworks including expert determination, binding arbitration, mediation, and hybrid approaches. | |||||||||||||
| OpenPGP Key Replacement | ||||||||||||||
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) | ||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. | |||||||||||||
| Extension Registry for the Extensible Provisioning Protocol | ||||||||||||||
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. | |||||||||||||
| RESTful Provisioning Protocol (RPP) - Requirements | ||||||||||||||
|
This document describes the requirement for the development of the RESTful Provisioning Protocol (RPP). | |||||||||||||
| Text in RFCs | ||||||||||||||
|
The early policy for the RFC Series was that RFCs could only contain characters from the ASCII character set. Later policy, from RFC 7997, allowed more characters and enforced an encoding for RFCs of UTF-8. Since RFC 7997 was published, the IETF community has had much more experience of using non-ASCII characters in RFCs. The policy for the RFC Series is that all displayable text is allowed as long as the reader of an RFC can interpret that text. This document obsoletes RFC 7997. [[ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ]] | |||||||||||||
| Intra-domain Source Address Validation (SAVNET) Architecture | ||||||||||||||
|
This document specifies the architecture of intra-domain SAVNET, which aims to achieve accurate source address validation (SAV) at external interfaces of an intra-domain network in an automated manner. It describes the conceptual design of intra-domain SAVNET, along with its use cases and design requirements, to help ensure that the intended objectives are met. | |||||||||||||
| Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6) | ||||||||||||||
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment Identifier (PSID) has been defined to identify an SR path in SR-MPLS networks, and is used for various use- cases such as end-to-end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the PSID to identify an SRv6 path in an IPv6 network. | |||||||||||||
| SRv6 for Redundancy Protection | ||||||||||||||
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability of service transmission in Segment Routing networks. The mechanism uses the "Live-Live" methodology. This document introduces one new SRv6 Segment Endpoint Behavior to provide replication and elimination functions on specific network nodes by leveraging SRv6 Network Programming capabilities. | |||||||||||||
| YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics | ||||||||||||||
|
This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. | |||||||||||||
| Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
Distributed computing is a computing pattern that service providers can follow and use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, compute intensive and delay sensitive services can be improved by utilizing computing resources hosted in various computing facilities. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response time. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to better meet the customer's expectations. | |||||||||||||
| FN-DSA for JOSE and COSE | ||||||||||||||
|
This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 206 (expected to be published in late 2026 early 2027). It does not define new cryptographic primitives; rather, it specifies how existing FN-DSA mechanisms are serialized for use in JOSE and COSE. This document registers signature algorithms for JOSE and COSE, specifically FN-DSA-512 and FN-DSA-1024. | |||||||||||||
| SLH-DSA for JOSE and COSE | ||||||||||||||
|
This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post- Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. | |||||||||||||
| Network File System (NFS) Version 4 Minor Version 1 Protocol | ||||||||||||||
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made and part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. | |||||||||||||
| A YANG Data Model for Network Incident Management | ||||||||||||||
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and probable cause analysis. | |||||||||||||
| Formal SignWriting | ||||||||||||||
|
Formal SignWriting is a character encoding model for Sutton SignWriting, a script for writing sign languages recognized under ISO 15924 script code "Sgnw". It defines a sign as a two-part word, represented as a string of characters processable by regular expressions, optimized for display, searching, sorting, and text processing. This document specifies the character sets, grammar, token patterns, and technical integration for Formal SignWriting in ASCII (FSW) and SignWriting in Unicode (SWU), including styling, query language, and transformations. The specification is intended for implementation and evaluation, with unrestricted distribution. | |||||||||||||
| IETF Network Slice Service Mapping YANG Model | ||||||||||||||
|
This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/ VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models. | |||||||||||||
| Timeslot Queueing and Forwarding Mechanism | ||||||||||||||
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. | |||||||||||||
| Public Key Derived HMAC for JOSE | ||||||||||||||
|
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). | |||||||||||||
| Considerations for SRv6 MSD Limitation in PCEP | ||||||||||||||
|
This document analyzes the impact of different SRv6 MSDs when PCE sends SR-TE paths to the PCE. And it updates the MSD restrictions in RFC9603 based on the analysis. This document also specifies a procedure for optimizing the number of SIDs in an SRv6-TE path that PCE can compute when the reduced SRH mode is used. | |||||||||||||
| A Survey to Determine MPLS Label Stack Inspection Behavior | ||||||||||||||
|
As part of the work on MPLS Network Actions (MNA) a debate arose concerning how existing MPLS implementations handle Special Purpose Labels (SPLs) especially in the context of processing the MPLS Entropy Label. The question applies to the relative placement of the Entropy Label Indicator (ELI) and the MNA Base SPL in the MPLS label stack. This question is applicable to the use of the ELI and any new base SPL (bSPL), or to the relative placement of any two bSPLs including the Extension Label that precedes any extended SPL. In order to discover what deployed implementations currently do, it is proposed that the MPLS working group chairs poll participants to answer specific questions about their implementations. This document is a working draft of the questions to be asked. It is not intended that this document should progress to publication as an RFC. | |||||||||||||
| PCE Redundancy Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). A PCE redundance case is very important and has no real solution for many cases, like as active-standby, active-active or not concurrent sessions of PCC with different PCEs. This document proposes extensions to PCEP to allow a PCC and PCEs to support PCE fast and smooth redundancy in case of PCEP session and PCE failure. | |||||||||||||
| X.509 Extensions for PQC or Composite Certificate Hosting Continuity | ||||||||||||||
|
This document specifies a new X.509 certificate extension, Post- Quantum or Composite Hosting Continuity (PQCHC), which enables a certificate subject to signal a intent to continue serving PQC or composite certificates for a defined continuity period after certificate expiration. This extension helps relying parties detect downgrade and man-in-the-middle (MitM) attacks during transition phases, where a cryptographically relevant quantum computer (CRQC) would make traditional certificates insecure. | |||||||||||||
| Traffic Engineering (TE) and Service Mapping YANG Data Model | ||||||||||||||
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. | |||||||||||||
| SDP Offer/Answer for RTP over QUIC (RoQ) | ||||||||||||||
|
This document is intended to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. The document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/ Answer can be used to set up an RTP connection using QUIC. This document also contains non-normative guidance for implementers. | |||||||||||||
| DetNet multidomain extensions | ||||||||||||||
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. | |||||||||||||
| Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network | ||||||||||||||
|
This document describes the use cases and related requirements of Massive Data Transmission（MDT）in High Bandwidth-delay Product (BDP) Network. The MDT framework enables efficient use of nighttime idle bandwidth to provide services such as same-day or next-day delivery. To meet these objectives, the system introduces a terminal-driven intelligent parameter optimization method that adjusts local configurations (e.g., disk I/O, NIC bandwidth, TCP buffer) to match transmission goals. This document outlines the end-to-end architecture and key mechanisms including service identification and traffic statistics, network layer load balancing, transmission protocol optimization, collaboration between terminal APP, network device and controller, etc. | |||||||||||||
| DKIM Access Control and Differential Changes | ||||||||||||||
|
This document specifies a DKIM (RFC 6376) extension that allows cryptographic verification of SMTP (RFC 5321) envelope data, and of DKIM signatures prior to IMF (RFC 5322) message content changes along the message path, addressing thus security glitches, and offering a new world of email solutions that move complexity away from lower network layers, where problems cannot be solved, complying with David Wheeler's fundamental theorem of software engineering, that "We can solve any problem by introducing an extra level of indirection". It updates DKIM to obsolete certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. It is the future of email for email of the future. | |||||||||||||
| Proactive Flow Control Point Detection in WAN | ||||||||||||||
|
This document proposes a proactive detection mechanism for flow control in WAN, letting the congested node to know precisely which upstream point should the flow control message be sent to. | |||||||||||||
| xxHash fast digest algorithm | ||||||||||||||
|
Description of the xxHash fast digest algorithm. 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-xxhash/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-xxhash. | |||||||||||||
| The Base16,Base32,and Base64 Data Encodings | ||||||||||||||
|
This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. This document obsoletes RFC 4648 and changes the status to Internet Standard. | |||||||||||||
| SCIM Agents and Agentic Applications Extension | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) specification [RFC7643] provides schemas that represent common identity information about users and groups, as well as a protocol for communicating that information between systems. The systems that tend to implement SCIM clients and servers are identity providers, and service providers. These are the same systems that are now need to manage agents and agentic applications across domains. This document describes a SCIM 2.0 extension for agents and agentic applications, which includes extensions to the core User and Group objects, and new resource types and schemas for agentic constructs. This extension is intended to provide greater interoperability between Identity providers, agentic applications, agents and their clients while reducing the responsibilities assumed by the every growing list of new protocols for agents. | |||||||||||||
| A YANG Data Model for Optical Impairment-aware Topology | ||||||||||||||
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for a Wavelength Switched Optical Network (WSON), while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for a Spectrum Switched Optical Network (SSON). This document provides a YANG data model for the impairment-aware TE topology in optical networks. | |||||||||||||
| Common YANG Data Types for Layer 0 Optical Networks | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. | |||||||||||||
| BMP v4: TLV Support for BGP Monitoring Protocol (BMP) Route Monitoring and Peer Down Messages | ||||||||||||||
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types. Additionally, this document introduces support for enterprise- specific TLVs in the BGP Monitoring Protocol by defining an Enterprise Bit (E-bit) that allows usage of per-vendor Type values. | |||||||||||||
| IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option | ||||||||||||||
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. | |||||||||||||
| Proxying Ethernet in HTTP | ||||||||||||||
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. | |||||||||||||
| YANG Groupings for UDP Clients and UDP Servers | ||||||||||||||
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. | |||||||||||||
| Crowd Sourced Remote ID | ||||||||||||||
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. | |||||||||||||
| BGP Extensions of SR Policy for Headend Behavior | ||||||||||||||
|
RFC8986 defines H. Encaps behavior, H. Encaps.Red behavior, H. Encaps.L2 behavior, and H. Encaps.L2.Red behavior for SR policy. This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. | |||||||||||||
| Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) Framework | ||||||||||||||
|
This document describes the OAM framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and OAM components. It also describes the requirements to enable the fault and the performance management of end-to-end connections from clients to networks and finally to services instances. | |||||||||||||
| RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement | ||||||||||||||
|
This document describes a mechanism for signaling which video frames have been received and decoded by a remote peer. It comprises an RTCP feedback message and an RTP header extension used to request said feedback. One of the main use cases for this data is to implement various forms of Long Term Reference (LTR) reference structures. | |||||||||||||
| Announce Existence of Parent CDS/CSYNC Scanner | ||||||||||||||
|
In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties. This document proposes an extension to the semantics of the DSYNC resource record, as defined in [RFC9859], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP as described in RFC9604. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. | |||||||||||||
| Best Current Practice for ROA Issuance Restrictions in RPKI | ||||||||||||||
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It mandates that a parent Certification Authority (CA) MUST NOT issue ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are required to enforce this restriction by rejecting or flagging invalid ROAs issued outside of resource allocations. | |||||||||||||
| Exchanging Congestion Control Data in QUIC | ||||||||||||||
|
This draft defines a new transport frame which enables consenting endpoints to share congestion control state about the network connection for various purposes. It also allows an endpoint's own congestion control state to be echoed back to it by a peer for consideration at the beginning of a future connection. | |||||||||||||
| Applicability of CATS Framework | ||||||||||||||
|
The IETF CATS WG considers the problem of how the network edge can steer traffic between clients of a service and the sites offering the service. The service QoE and/or the performance experienced by edge clients may depend on both network metrics and compute metrics. CATS leverages these metrics and strives to optimize how a network edge node may steer traffic, as appropriate to the service. Revolving around the 'optimized' objective, the CATS Framework proposes and defines a general architecture for the distribution of network and compute metrics and for the transport of traffic from network edge to service instance. This draft illustrates the applicability of the CATS framework to various noteworthy scenarios. | |||||||||||||
| PKIX Evidence for Remote Attestation of Hardware Security Modules | ||||||||||||||
|
This document specifies a vendor-agnostic format for evidence produced and verified within a PKIX context. The evidence produced this way includes claims collected about a cryptographic module and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce evidence tailored for expected use. | |||||||||||||
| RPP Architecture | ||||||||||||||
|
Advancements in development, integration, deployment environments and operational paradigms have led to a desire for an alternative for the Extensible Provisioning Protocol (EPP). This document defines the architecture for the RESTful Provisioning Protocol (RPP) an HTTP based provisioning protocol leveraging the REST architectural style and JSON data-interchange format, aiming to standardize a RESTful protocol for provisioning database objects. The architecture includes support for extensibility, allowing for multiple possible use cases. RPP is intended to co-exist with EPP, offering an alternative protocol including data model compatibility with EPP core objects and the benefits associated with the REST architectural style and widely adopted HTTP-based technologies. | |||||||||||||
| General Source Address Validation Capabilities | ||||||||||||||
|
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. | |||||||||||||
| Protocol Numbers for SCHC | ||||||||||||||
|
This document requests an Internet Protocol Number, an Ethertype assignment and well known ports for SCHC. The SCHC architecture, the SCHC instance establishment, and the SCHC compression/decompression processes are simplified when SCHC is easily recognised. Well-known protocol and port numbers are needed. The Internet Protocol Number request is so that SCHC can be used for IP independent of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. | |||||||||||||
| An Architecture for Trustworthy and Transparent Digital Supply Chains | ||||||||||||||
|
Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. | |||||||||||||
| Automatically Connecting Stub Networks to Unmanaged Infrastructure | ||||||||||||||
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). | |||||||||||||
| Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs | ||||||||||||||
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. | |||||||||||||
| Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 | ||||||||||||||
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. | |||||||||||||
| TVR (Time-Variant Routing) Requirements | ||||||||||||||
|
Time-Variant Routing (TVR) refers to calculating a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements where TVR computations could improve message exchange in a network. | |||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting | ||||||||||||||
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. | |||||||||||||
| VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 | ||||||||||||||
|
This draft defines a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwardings (VRFs) are exchanged through a single shared Border Gateway Protocol (BGP) session. | |||||||||||||
| YANG Data Model for Automatic Multicast Tunneling | ||||||||||||||
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. | |||||||||||||
| Adaptive Subscription to YANG Notification | ||||||||||||||
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. | |||||||||||||
| Brand Indicators for Message Identification (BIMI) | ||||||||||||||
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. | |||||||||||||
| YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) | ||||||||||||||
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. | |||||||||||||
| Extending YANG modules at runtime | ||||||||||||||
|
This document describes a mechanism of signaling extensions to YANG modules that can be used when YANG is not used in an online fashion. | |||||||||||||
| Advertising Flexible Algorithm Extensions in BGP Link-State | ||||||||||||||
|
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. | |||||||||||||
| Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV) | ||||||||||||||
|
This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact. | |||||||||||||
| A Bound End-to-End Tunnel (BEET) mode for ESP | ||||||||||||||
|
This document is an update to the Bound End-to-End Tunnel (BEET) mode for ESP in as described in [RFC7402]. It brings the description in alignment with the addition of BEET mode for IKEv2 without any processing changes as described in [RFC7402] | |||||||||||||
| Congestion Control Based on SRv6 Path | ||||||||||||||
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. | |||||||||||||
| Indication of Load-balancing Strategy | ||||||||||||||
|
This document proposes the encoding of the indication for load- balancing strategies which can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. It also provides the considerations for load-balancing configuration in control plane as well. | |||||||||||||
| Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping | ||||||||||||||
|
SR Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanism and installed via, e.g., a Path Computation Element (PCE). In other cases these policies can be installed via using NETCONF/YANG or CLI. They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers. This document defines extensions to Ping and Traceroute mechanisms for SR P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities. The extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within SR P2MP Policy multicast trees. By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing SR P2MP Policies. | |||||||||||||
| Epoch Markers | ||||||||||||||
|
This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. | |||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) | ||||||||||||||
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture | |||||||||||||
| Optimizing BFD Authentication | ||||||||||||||
|
This document describes an experimental optimization to BFD Authentication. This optimization enables BFD to scale better when there is a desire to use authentication where applying the same authentication mechanism to every BFD Control Packet may adversely impact performance. This optimization partitions BFD Authentication into a more computationally intensive mechanism that is applied to BFD significant changes, and a less computationally intensive mechanism applied to the majority of BFD Control Packets. | |||||||||||||
| Increase of the Congestion Window when the Sender Is Rate-Limited | ||||||||||||||
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. | |||||||||||||
| JSON Meta Application Protocol (JMAP) for Calendars | ||||||||||||||
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. | |||||||||||||
| QUIC-Aware Proxying Using HTTP | ||||||||||||||
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. | |||||||||||||
| Sub-interface VLAN YANG Data Models | ||||||||||||||
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic originating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| Inter Domain considerations for Constrained Route distribution | ||||||||||||||
|
RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). RFC4684 addresses both intra domain and inter domain distributions. Operational deployment experience shows that the current distribution model defined in RFC4684 for inter domain may cause some issue in specific scenarios. This document proposes alternate route distribution rules for inter domain in order to address these specific scenarios. | |||||||||||||
| A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information | ||||||||||||||
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation information in the DNS. | |||||||||||||
| Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification | ||||||||||||||
|
This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. | |||||||||||||
| A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks | ||||||||||||||
|
This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to the operation of an IEEE 802.11 wireless network. | |||||||||||||
| AgentDNS: A Root Domain Naming System for LLM Agents | ||||||||||||||
|
This document describes AgentDNS, a root domain naming and service discovery system designed for Large Language Model (LLM) agents. Inspired by the traditional Domain Name System (DNS), AgentDNS enables agents to autonomously discover, resolve, and securely invoke third-party agent and tool services across different vendors. AgentDNS introduces a unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication and billing. The system aims to address interoperability, service discovery, and trust management challenges in large-scale agent collaboration ecosystems. | |||||||||||||
| OAuth Client ID Metadata Document | ||||||||||||||
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. | |||||||||||||
| Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service | ||||||||||||||
|
For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an multi-domain IPv6-only environment(i.e.,IPv4-as- a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, examines the utilization of SRv6, and discusses the security considerations. | |||||||||||||
| RTP Payload Format for SFrame | ||||||||||||||
|
This document describes the RTP payload format of SFrame. | |||||||||||||
| Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements | ||||||||||||||
|
Authoritative control of parts of the Domain Name System namespace are indicated with a special record type, the NS record, that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft considers the limitations of the current system, benefits that could be gained by changing it, and what requirements constrain an updated design. | |||||||||||||
| Integration of DNS Domain Names into Application Environments: Motivations and Considerations | ||||||||||||||
|
This document describes considerations when integrating a DNS domain name into an application environment. Goals of this document include minimizing conflicts between the global DNS and applications that integrate with the global DNS, providing a consistent user experience (unique identifier across environments), and extending the security, stability, and resiliency of the global DNS. While all sources of potential concern cannot be enumerated in one document, accounting for at least the considerations discussed here should improve the security posture of both the global DNS and integrating applications. | |||||||||||||
| BGP Operations and Security | ||||||||||||||
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability requirements that can and should be ensured to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454 / BCP194, several developments and changes in operational practice took place that warrant an update of these best current practices. This document replaces RFC7454 / BCP194, focusing on the overall goals, and providing a less implementation centric set of best practices. This document describes security requirements and goals when operating BGP for exchanging routing information with other networks, and explicitly does not focus on specific technical implementations and requirements. | |||||||||||||
| Currently Used Terminology in Global Routing Operations | ||||||||||||||
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. | |||||||||||||
| Current Options for Securing Global Routing | ||||||||||||||
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. | |||||||||||||
| Encrypted ESP Echo Protocol | ||||||||||||||
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. | |||||||||||||
| Transaction ID Mechanism for NETCONF | ||||||||||||||
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration datastores. The volume of configuration data in a server may be very large, while datastore changes typically are small when observed at typical client resynchronization intervals. Rereading the entire datastore and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. | |||||||||||||
| Secure hybrid network monitoring - Problem statement | ||||||||||||||
|
This document describes a problem statement regarding the challenges and requirements for ensuring and monitoring the security status of networks operating in complex environments, such as hybrid or mixed cloud systems. | |||||||||||||
| Crawler best practices | ||||||||||||||
|
This document describes best pratices for web crawlers. 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/garyillyes/cbcp. | |||||||||||||
| Automatic Minutes Generation | ||||||||||||||
|
RFC 2418 requires that working group chairs ensure that sessions shall "be reported by making minutes available". Those minutes can be automatically generated from meeting recordings. This document requests that the IETF LLC update the meeting tooling to facilitate this. | |||||||||||||
| Verified Email Identity Framework (VEIF) | ||||||||||||||
|
This document proposes the Verified Email Identity Framework (VEIF), a mechanism to ensure that every email address used for sending electronic mail is associated with a verifiable and accountable registrant. The goal is to significantly reduce spam, phishing, and identity abuse by introducing individual-level authentication in addition to existing domain-level controls such as SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489]. | |||||||||||||
| AGENTS.TXT: Strict Policy File for Automated Clients | ||||||||||||||
|
This document specifies the AGENTS.TXT protocol, a strict plaintext policy file for automated clients, bots, and crawlers. It defines directives, top-line hash verification, optional parameters, and mandatory failure behavior for malformed files. Malformed files are treated as fully restrictive to prevent unintended access. | |||||||||||||
| Secure Hybrid Network Monitoring - Path Characteristics Service | ||||||||||||||
|
"Secure hybrid network monitoring - Problem statement" identifies challenges in securing and monitoring networks deployed across hybrid and mixed cloud environments. This document introduces the Path Characteristics Service (PCS), a framework that enables applications and operators to obtain and evaluate verifiable information about the characteristics of the network paths they use. It outlines a non- normative architecture and interfaces for PCS and explains how PCS can help address the identified challenges; it does not define protocol requirements. | |||||||||||||
| Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants | ||||||||||||||
|
This specification updates the requirements for audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. | |||||||||||||
| A YANG Data Model and RADIUS Extension for Policy-based Network Access Control | ||||||||||||||
|
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. | |||||||||||||
| Mobility-aware Transport Network Slicing for 5G | ||||||||||||||
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. | |||||||||||||
| BGP Link Bandwidth Extended Community | ||||||||||||||
|
This document specifies a type of BGP Extended Community that enables routers to perform weighted load-balancing in multipath scenarios. | |||||||||||||
| Use of Variable-Length Output Pseudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFCs 5723, 6617, 6631, 7296, 8784, 9370 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. | |||||||||||||
| Separate Transports for IKE and ESP | ||||||||||||||
|
The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. | |||||||||||||
| Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that aims to prevent some kinds of downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. | |||||||||||||
| LISP Traffic Engineering | ||||||||||||||
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new Routing Locator encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. | |||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. | |||||||||||||
| YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also specifies the initial version of IANA-maintained YANG modules for IGP Algorithm Types and IGP Metric-Type. | |||||||||||||
| YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. | |||||||||||||
| Registry policies "... with Expert Review" | ||||||||||||||
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. To support its objectives for the period of time while the above updates have not yet been finalized, this document offers text that can be copy-pasted into specifications that want to make use of the augmented policies. // —— Editors' note: —— As to augmenting existing policies, the // provided proposals have been considered in // [I-D.baber-ianabis-rfc8126bis] within the IANABIS Working Group. // This topic is covered by Section 2 of our draft and there is a // placeholder "ADD NEW PROCEDURE" about it at Section 4 of // [I-D.baber-ianabis-rfc8126bis]. However, compared to our draft, // this is not augmenting the policy "IESG Approval". On the topic // of early registration covered by Section 3 of our draft, we were // under the impression that something similar could be argued about // it too, but not quite (yet). Looking at // [I-D.baber-ianabis-rfc7120bis], there seems to be no text or // placeholders on that topic yet. We expect such text to come in // the future, to ensure that the early allocation procedure is fully // specified also for registries that use the augmented policies. | |||||||||||||
| Use Cases for Energy Efficiency Management | ||||||||||||||
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-use-cases | |||||||||||||
| Encrypted Authenticated Resource Locator | ||||||||||||||
|
This document describes the Encrypted Authenticated Resource Locator (EARL) URI scheme and the encoding and decoding of the associated content data. An EARL is a bearer token that allows an encrypted data object to be located, decrypted and authenticated using a compact URI form designed for human readability. A range of work factors is supported from 2^112 to 2^252. The plaintext data format consists of an initial header section containing metadata describing the payload, the payload itself and an optional section containing signature data. | |||||||||||||
| A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel Support | ||||||||||||||
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. | |||||||||||||
| vCon World Transcription Format Extension | ||||||||||||||
|
This document defines the World Transcription Format (WTF) extension for Virtualized Conversations (vCon). The WTF extension provides a standardized analysis framework for representing speech-to-text transcription data from multiple providers within vCon containers. This extension defines a comprehensive analysis format that enables consistent transcription processing, quality assessment, and interoperability across different transcription services while preserving provider-specific features through extensible fields. The WTF extension is designed as a Compatible Extension that introduces a new analysis type for transcription data without altering existing vCon semantics, ensuring backward compatibility with existing vCon implementations. | |||||||||||||
| Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies how Classic McEliece Key Encapsulation Mechanism (KEM) is used to generate keys in the Internet Key Exchange version 2 (IKEv2) protocol. | |||||||||||||
| Data At Rest Envelope (DARE) | ||||||||||||||
|
This document describes the Data At Rest Envelope (DARE) Envelope and Sequence. The DARE Envelope syntax is used to package plaintext or encrypted content payload and metadata with JOSE decryption and signature data authenticating the payload and metadata. The DARE Sequence format comprises a sequence of DARE Envelopes. The binary encoding of DARE envelopes allows compact encoding of encrypted and signed payloads of unknown length in a single pass with minimal overhead. The binary encoding of DARE sequences is designed to support an append only write mode and efficient reading in either the forwards or backwards directions. The JSON encoding of DARE Envelopes and sequences allows envelopes and sequences to be incorporated in other JSON objects. This document does not cover construction of indexes or signatures over multiple entries in a sequence. | |||||||||||||
| The AEGIS Family of Authenticated Encryption Algorithms | ||||||||||||||
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. 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/cfrg/draft-irtf-cfrg-aegis-aead. | |||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using IOAM data fields. | |||||||||||||
| Use of Remote Attestation with Certification Signing Requests | ||||||||||||||
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of RATS conceptual messages (see Section 8 of [RFC9334], such as Evidence, Endorsements and Attestation Results, in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting attestation data to a Certification Authority. Including Evidence, Endorsements and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. | |||||||||||||
| The DNSCrypt Protocol | ||||||||||||||
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation, providing a standardized approach to securing DNS communications. DNSCrypt improves confidentiality, integrity, and resistance to attacks affecting the original DNS protocol while maintaining compatibility with existing DNS infrastructure. | |||||||||||||
| FC-BGP Protocol Specification | ||||||||||||||
|
This document defines an extension, Forwarding Commitment BGP (FC- BGP), to the Border Gateway Protocol (BGP). FC-BGP provides security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. Forwarding Commitment (FC) is a cryptographically signed segment to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in the BGP UPDATE message and alleviate route leaks in the BGP routing system. The extension is backward compatible, which means a router that supports the extension can interoperate with a router that doesn't support the extension. | |||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS extension headers, including MPLS Network Action Sub-Stacks and Post-Stack Header, for HBH and E2E active measurements, for example, using IOAM data fields. | |||||||||||||
| A Historical Analysis of Design Lessons from The Reliable Data Protocol Version 1 and Version 2 | ||||||||||||||
|
This document reviews and analyzes the history and experience of the Reliable Data Protocol. RDP was initially published as an experimental protocol in RFC 908 in 1984 and subsequently revised in RFC 1151 in 1991. RDP aimed to provide a message-oriented, reliable transport service to meet specific application requirements such as remote loading. This document summarizes the key technical experiences gained from RDP's experimental deployment, details the lessons learned regarding checksum performance and flow control mechanisms, and assesses the conceptual influence of its design principles on subsequent IETF transport protocols. The document is intended for historical archiving, providing a reference for early explorations of Internet transport protocols, and does not propose any new standards or deployment recommendations. | |||||||||||||
| Null Scheme for Signed Objects in the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI). The Null Scheme is a niche signature scheme that can replace the redundant and costly use of actual digital signatures from so-called "one-time-use" key pairs in Signed Objects. The Null Scheme has as public key the digest of the message to be signed, and the signature is always empty. When a Null Scheme public key is the subject of a Signed Object's one-time- use End-Entity (EE) certificate, it establishes a secure binding between the issuer of the EE certificate and the message to be signed. This is cheaper in terms of size and verification time than using a real signature scheme, while providing the same security guarantees. | |||||||||||||
| The Meta-Layer: A Coordination Substrate for Presence,Annotation,and Governance on the Web | ||||||||||||||
|
This document introduces the concept of a Meta-layer: a programmable coordination substrate that operates above content layers on the Internet. The Meta-layer enables communities, individuals, and agents to appear, annotate, and govern together in shared digital space, independent of underlying platforms. It is not a replacement for existing web or transport protocols, but a complementary infrastructure that integrates with them. The draft outlines the motivation, terminology, use cases, implementation model, risks, security considerations, and potential IANA registries for future work. | |||||||||||||
| LISP Multicast Deployment Experience | ||||||||||||||
|
We present our experiences in supporting deployments of LISP Multicast using unicast and multicast underlays. This document details design considerations that can be useful for anyone interested in deploying LISP multicast services over IP networks. | |||||||||||||
| Automated Certificate Management Environment (ACME) Device Attestation Extension | ||||||||||||||
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. | |||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE | ||||||||||||||
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. 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-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. | |||||||||||||
| PKCS #8 Private-Key Information Content Types | ||||||||||||||
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. | |||||||||||||
| MPLS Network Action (MNA) Sub-Stack Solution | ||||||||||||||
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. The solution specified in this document addresses the requirements for In-stack network action and In-stack data found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". | |||||||||||||
| A Decent LISP Mapping System (LISP-Decent) | ||||||||||||||
|
This draft describes how the LISP mapping system can be distributed for scale, decentralized for management and maintain trust among data-plane nodes. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. | |||||||||||||
| A YANG Data Model for Microwave Radio Link | ||||||||||||||
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. | |||||||||||||
| Enhanced Dynamic Capability for BGP | ||||||||||||||
|
This document addresses the limitations with the BGP Dynamic Capability specification by introducing additional protocol extensions and operational procedures so that a BGP capability that requires bi-directional capability advertisement can be revised dynamically. | |||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction, referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of residual bit error rate within the "Extra Padding" TLV of STAMP packets. | |||||||||||||
| OAuth SPIFFE Client Authentication | ||||||||||||||
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. | |||||||||||||
| Certificate Renewal Recommendations for Enrollment over Secure Transport | ||||||||||||||
|
This document describes an extension to RFC7030, Enrollment over Secure Transport to give an indication to a end-entity device when it should start attempting to renew its certificates. Prior art is that client decides, with a typical recommmendation to start when the remaining lifetime of the certificate is at the 50% point. As typical certificate lifetimes are reduced from years to fractions of a year, the 50% may be far too early, and this document provides a way to give alternate advice. | |||||||||||||
| AI URI Scheme | ||||||||||||||
|
This document specifies the experimental ai Uniform Resource Identifier (URI) scheme. The scheme provides a dedicated access point for Artificial Intelligence (AI) resources, enabling autonomous systems and robots to connect natively while allowing human-facing applications to interoperate via HTTPS gateways. | |||||||||||||
| Unbound DATA Frames in HTTP/3 | ||||||||||||||
|
This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a request or response stream, it indicates that all subsequent octets on that stream are interpreted as data. This applies both to message body data and to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived or indeterminate-length payloads. | |||||||||||||
| Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case | ||||||||||||||
|
This document explores how existing IETF YANG data models, specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and Traffic Engineering (TE) topology data models, can be applied to support a use case involving dynamic AI model placement at Edge Cloud sites. The use case involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG data models to retrieve and request specific services objectives such as bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model applicability and identify gaps, if any. | |||||||||||||
| Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements | ||||||||||||||
|
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. | |||||||||||||
| Partially Blind RSA Signatures | ||||||||||||||
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. | |||||||||||||
| LISP Map Server Reliable Transport | ||||||||||||||
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New LISP use cases increase the amount of state that needs to be communicated and challenge the scalability of the system when using the UDP exchange. This document introduces the use of a reliable transport for ETR to Map-Server communications in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. | |||||||||||||
| Open Cloud Mesh | ||||||||||||||
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. | |||||||||||||
| An EAT Profile for Device Attestation | ||||||||||||||
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust the device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be consumed by 3rd party attestation services external to the TVM, there is a need to standardise the representation of Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. | |||||||||||||
| Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness | ||||||||||||||
|
This document standardizes usage of Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) as identifiers to enable trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems (UAS) in Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). DETs can serve as Session IDs for privacy, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. | |||||||||||||
| The Transport Layer Security (TLS) Protocol Version 1.4 | ||||||||||||||
|
This contribution has been withdrawn. | |||||||||||||
| Human Readable Validate ROA Payload Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. | |||||||||||||
| Human Readable ASPA Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). | |||||||||||||
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane | ||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for SR-MPLS paths (including SR-MPLS Policies, SR-MPLS IGP best paths, and SR- MPLS IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SR-MPLS paths. | |||||||||||||
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane | ||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement for SRv6 using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SRv6 paths (including SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths. | |||||||||||||
| Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) | ||||||||||||||
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. | |||||||||||||
| Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) | ||||||||||||||
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a TLS server. Bootstrapping devices have a public/private key pair, and this mechanism enables a TLS server to prove to the device that it knows the public key, and the device to prove to the TLS server that it knows the private key. The mechanism leverages existing Device Provisioning Protocol (DPP) and TLS standards and can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server. | |||||||||||||
| Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields for Intra-IOAM-Domain use cases. | |||||||||||||
| Clarification to processing Key Usage values during CRL validation | ||||||||||||||
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. | |||||||||||||
| Post-Stack MPLS Network Action (MNA) Solution | ||||||||||||||
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data specific requirements found in "RFC 9613". This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "RFC 9789". | |||||||||||||
| Just because it's an Internet-Draft doesn't mean anything... at all... | ||||||||||||||
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. | |||||||||||||
| Compact Routing Header (CRH) Helper Option | ||||||||||||||
|
This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes. | |||||||||||||
| Email Feedback Reports for DKIM Signers | ||||||||||||||
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. | |||||||||||||
| Making LocalRoot a Best Current Practice | ||||||||||||||
|
RFC 8806 (often called "LocalRoot") defines a mechanism whereby a recursive resolver can fetch the contents of an entire zone and place this information into the resolver's cache. This has several benefits, including increased reliability, increased performance, improved privacy, and decreased or mitigation of the effect of some types of DoS attacks. While the majority of DNS resolver implementations natively support RFC 8806, it remains tricky to configure and maintain. This document recommends that DNS resolver software simplify this configuration, and further suggests that configuration becomes the default. This document updates Section 2 of RFC8806 by relaxing the requirement that implementations MUST run an authoritative service. /* Ed (WK): Open questions / ToDo / Notes (to be removed before publication): | |||||||||||||
| Vocabulary For Expressing Content Signals | ||||||||||||||
|
This Internet Draft proposes three categories that would enable parties to express preferences regarding how digital assets are used by automated processing systems. The proposal is for these categories to nest within the larger category of Automated Processing, currently envisaged in the [AIPREF-VOCAB]. | |||||||||||||
| Applicability of TCP-AO for Securing NETCONF and gNMI | ||||||||||||||
|
This document analyzes the applicability of the TCP Authentication Option (TCP-AO) to secure TCP-based network management protocols, specifically NETCONF and gNMI. It describes deployment profiles in which TCP-AO provides per-connection integrity and peer authentication with low operational overhead, either as an alternative to or in combination with TLS/SSH. This document gives guidance on key management (e.g., static keys and operational "key chains") and documents expected behaviors and benefits. No new protocol bits are defined and there are no IANA actions. | |||||||||||||
| Quantum FWM Control Protocol (QFCP) for IP Optical Environments | ||||||||||||||
|
This document specifies the Quantum Four-Wave Mixing Control Protocol (QFCP), a lightweight transport protocol designed to operate over UDP in IP optical environments. QFCP enables the transmission of control- plane parameters required for quantum four-wave mixing (FWM) processes and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. | |||||||||||||
| Route Server Next Hop Translation | ||||||||||||||
|
With the advent of RFC8950, Internet Exchang Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document updates RFC 6890 by registering a special-purpose address, and RFC 7947 by specifying an allowed route modification at the route server. | |||||||||||||
| Semantic Inference Routing Protocol (SIRP) | ||||||||||||||
|
This document specifies the Semantic Inference Routing Protocol (SIRP), a framework for content-level classification and semantic routing in AI inference systems. By analyzing the content of inference requests--rather than relying solely on client-supplied metadata--SIRP enables routing decisions that are more robust, consistent, and extensible. SIRP also defines optional value-added routing (VAR) extensions for cost optimization, urgency prioritization, domain specialization, and privacy-aware handling. | |||||||||||||
| Convergence of Congestion Control from Retained State | ||||||||||||||
|
This document specifies a cautious method for Internet transports that enables fast startup of congestion control for a wide range of connections, known as "Careful Resume". It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the congestion control behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of this method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. | |||||||||||||