Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These Internet-Drafts are listed alphabetically by working group acronym and start date. Generated 2025-06-17 07:05:50 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "Transmission of SCHC-compressed packets over IEEE 802.15.4 networks", Carles Gomez, Ana Minaburo, 2025-03-03, 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. "Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks", Luigi Iannone, Guangpeng Li, David Lou, Peng Liu, Pascal Thubert, 2025-03-03, This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables IP packet stateless forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. These specifications describe the PASA architecture, along with PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. "IPv6 Neighbor Discovery Prefix Registration", Pascal Thubert, 2025-06-06, This document updates Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request neighbor router(s) to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document extends Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. "Transmission of IPv6 Packets over Short-Range Optical Wireless Communications", Younghwan Choi, Cheol-min Kim, Carles Gomez, 2025-02-27, 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. 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. "Generic Address Assignment Option for 6LoWPAN Neighbor Discovery", Luigi Iannone, David Lou, Adnan Rashid, 2025-03-16, This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks, enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. "Fixing the C-Flag in EARO", Pascal Thubert, Adnan Rashid, 2025-05-19, This document updates RFC 8928, “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks” (AP-ND), by updating the bit position for the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. IPv6 Maintenance (6man) ----------------------- "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson, Jen Linkova, 2025-03-03, 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, and RFC 8106. "Limits on Sending and Processing IPv6 Extension Headers", Tom Herbert, 2025-02-27, This document defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. Limits are pragmatic to facilitate interoperability amongst hosts and routers, thereby increasing the deployability of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. "Carrying Network Resource (NR) related Information in IPv6 Extension Header", Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma, Gyan Mishra, 2025-03-02, 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 are used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along a 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 also be generalized for other network resource semantics and functions. "IPv6 Query for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, 2025-06-10, This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. "Architecture and Framework for IPv6 over Non-Broadcast Access", Pascal Thubert, Michael Richardson, 2025-05-19, This document presents an architecture and framework for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. "Prioritizing known-local IPv6 ULAs through address selection policy", Nick Buraglio, Tim Chown, Jeremy Duncan, 2025-05-13, This document draws on several years of operational experience to update the recommended process of Default Address Selection for Internet Protocol Version 6 (IPv6) defined in RFC6724, defining the concept of "known-local" Unique Local Address (ULA) prefixes that enable ULA-to-ULA communications within fd00::/8 to become preferred over both IPv4-IPv4 and GUA-to-GUA (Global Unicast Addresses) for local use. The document defines the means by which nodes can both identify and insert such prefixes into their address selection policy table. It also clarifies the mandatory, unconditional requirement for support for Rule 5.5 defined in Section 5 of RFC6724 and demotes the preference for 6to4 addresses. These changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios, and makes preference for IPv6 over IPv4 consistent in local site networks for both ULA and GUA prefixes. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. "Entering IPv6 Zone Identifiers in User Interfaces", Brian Carpenter, Robert Hinden, 2025-05-19, This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874 and updates RFC 4007, RFC 7622 and RFC 8089. Discussion Venue This note is to be removed before publishing as an RFC. Discussion of this document takes place on the 6MAN mailing list (ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/ (https://mailarchive.ietf.org/arch/browse/ipv6/). "Deprecation Of The IPv6 Router Alert Option For New Protocols", Ron Bonica, 2025-04-29, This document deprecates the IPv6 Router Alert Option. Protocols that use the Router Alert Option may continue to do so, even in future versions. However, new protocols that are standardized in the future must not use the Router Alert Option. This document updates RFC 2711. "SNAC Router Flag in ICMPv6 Router Advertisement Messages", Jonathan Hui, 2024-12-04, This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices. "Clarification of IPv6 Address Allocation Policy", Brian Carpenter, Suresh Krishnan, David Farmer, 2025-05-12, This document specifies the approval process for changes to the IPv6 Address Space registry. It also updates RFC 7249. 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-6man-addr-assign/. Discussion of this document takes place on the 6MAN Working Group mailing list (mailto:ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/. Subscribe at https://www.ietf.org/mailman/listinfo/ipv6/. "The IPv6 VPN Service Destination Option", Ron Bonica, Xing Li, Adrian Farrel, Yuji Kamite, Luay Jalil, 2025-05-14, This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment. "Internet Control Message Protocol (ICMPv6) Reflection", Tal Mizrahi, Xiaoming He, Tianran Zhou, Ron Bonica, Xiao Min, 2025-05-19, This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a query to the probed node and the probed node responds to the query. The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the query, as it arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it allows the user to see how the network modified the query as it traveled from the probing node to the probed node. "IPv6 Node Requirements", Tim Chown, John Loughney, Timothy Winters, 2025-03-03, 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. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Marco Tiloca, Francesca Palombini, 2025-04-11, This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 access token. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, 2025-01-08, Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession, and server authentication. "EAP-based Authentication Service for CoAP", Rafael Marin-Lopez, Dan Garcia-Carrillo, 2025-02-19, This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund, 2025-03-03, 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", Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys, 2025-03-03, 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. "Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, 2025-01-08, Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. "Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework", Marco Tiloca, Goeran Selander, 2025-03-03, 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 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 extends the semantics of the "ace_profile" parameter. (3) It defines how the client and the authorization server 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. (4) It amends two of the requirements on profiles of the framework. (5) 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. "The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", Marco Tiloca, Rikard Hoeglund, Francesca Palombini, 2025-03-03, This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the client's public key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. "Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Marco Tiloca, John Mattsson, 2025-03-03, This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. "CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)", Francesca Palombini, Cigdem Sengul, Marco Tiloca, 2025-05-14, 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 for 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "ACME End User Client and Code Signing Certificates", Kathleen Moriarty, 2025-06-11, Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support service account authentication credentials, micro-service accounts credentials, device client, and code signing certificates and keys. "ACME Integrations for Device Certificate Enrollment", Owen Friel, Richard Barnes, Rifaat Shekh-Yusef, Michael Richardson, 2023-07-13, This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. "Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension", Brian Sipos, 2025-06-04, This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". "Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension", Aaron Gable, 2025-02-26, This document specifies how an ACME server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods. "Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names", Q Misell, 2025-01-15, The document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor hidden services (".onion" Special-Use Domain Names). Discussion 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/AS207960/acme-onion. The project website and a reference implementation can be found at https://acmeforonions.org. "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge", Antonios Chariton, Amir Omidi, James Kasten, Fotis Loukos, Stanislaw Janikowski, 2025-05-17, This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. By adding a unique label to the DNS validation record name, the dns-account-01 challenge avoids CNAME delegation conflicts inherent to the dns-01 challenge type. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. Adaptive DNS Discovery (add) ---------------------------- "Encrypted DNS Server Redirection", John Todd, Tommy Jensen, Corey Mosher, 2025-04-23, This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. AI Preferences (aipref) ----------------------- "Proposal for an Opt-Out Vocabulary", Paul Keller, Martin Thomson, 2025-04-30, This document proposes a standardized vocabulary of use cases that can be targeted when expressing machine-readable opt-outs related to Text and Data Mining (TDM) and AI training. The vocabulary is agnostic to specific opt-out mechanisms and enables declaring parties to communicate restrictions or permissions regarding the use of their digital assets in a structured and interoperable manner. It defines three key use cases—TDM, AI Training, and Generative AI Training—which can be referenced by opt-out systems to ensure consistent interpretation across different implementations. "Indicating Preferences Regarding Content Usage", Gary Illyes, Martin Thomson, 2025-06-15, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol", Jingxuan Zhang, Dhruv Dhody, Kai Gao, Roland Schott, Qiufang Ma, 2024-01-19, This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)", Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk, 2025-03-03, 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. "Join Proxy for Bootstrapping of Constrained Network Elements", Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk, 2025-01-23, 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 by a constrained node [RFC7228]. 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 extendible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks [RFC7228], including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC4944] based mesh 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 UDP communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow implementers to make different trade-offs regarding resource usage, implementation complexity and security. "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael Richardson, 2025-03-03, Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. This document extends BRSKI and defines new device behavior for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. "JWS signed Voucher Artifacts for Bootstrapping Protocols", Thomas Werner, Michael Richardson, 2025-01-15, This document introduces a variant of the RFC8366 voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515. This supports deployments in which JOSE is preferred over CMS. In addition to specifying the format, the "application/voucher-jws+json" media type is registered and examples are provided. "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson, 2025-06-03, This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). "A Voucher Artifact for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma, 2025-04-01, 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. Applications and Real-Time Area (art) ------------------------------------- "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", John Klensin, Asmus Freytag, 2025-02-06, The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFCs 5890 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. "Simple Public Key Infrastructure (SPKI) S-Expressions", Ronald Rivest, Donald Eastlake, 2025-01-10, This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI, RFC 2692) certificates and with the intent that it be more widely applicable. It has been and is being used elsewhere. There are multiple implementations in a variety of programming languages. Uses of this representation are referred to in this document as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: it gives a "canonical form" for them, describes two "transport" representations, and also describes an "advanced" format for display to people. "Unicode Character Repertoire Subsets", Tim Bray, Paul Hoffman, 2025-05-27, This document discusses subsets of the Unicode character repertoire for use in protocols and data formats, and specifies three subsets recommended for use in IETF specifications. Automatic SIP trunking And Peering (asap) ----------------------------------------- "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2025-03-31, 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. A Semantic Definition Format for Data and Interactions of Things (asdf) ----------------------------------------------------------------------- "Semantic Definition Format (SDF) for Data and Interactions of Things", Michael Koster, Carsten Bormann, Ari Keranen, 2025-03-17, 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. "An Application Layer Interface for Non-IP device control (NIPC)", Bart Brinckman, Rohit Mohan, Braeden Sanford, 2025-05-15, This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices, as well as a CBOR-based publish-subscribe interface for streaming data. The described interfaces are extensible. The specification also defines a protocol mapping function to to map this interface to commonly used non-IP protocols. "An sdfType for Links", Carsten Bormann, 2025-06-10, This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "RTP over QUIC (RoQ)", Mathis Engelbart, Joerg Ott, Spencer Dawkins, 2025-03-20, This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. "RTP Payload Format for Visual Volumetric Video-based Coding (V3C)", Lauri Ilola, Lukasz Kondrad, 2025-03-28, 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. "RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution", Yong He, Christian Herglotz, Edouard Francois, 2025-02-12, This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. "RTP Payload Format for sub-codestream latency JPEG 2000 streaming", Pierre-Anthony Lemieux, David Taubman, 2025-06-13, This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given image can be emitted before the entire image is available to, or encoded by, the sender. "RTP Payload Format for Haptics", Hyunsik Yang, Xavier de Foy, 2025-05-13, This memo describes an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS(MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP Payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for haptics/ hmpg, registered with IANA in RFC9695, did not include any required or optional parameters. This memo updates RFC9695 and the haptics/ hmpg registration to add optional parameters. "Absolute Capture Timestamp RTP header extension", Harald Alvestrand, 2025-02-06, This document describes an RTP header extension that can be used to carry information about the capture time of a video frame / audio sample, and include information that allows the capture time to be estimated by the receiver when the frame may have passed over multiple hops before reaching the receiver. "Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media", Srinivas Gudumasu, Ahmed Hamza, 2025-05-04, 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. BGP Enabled ServiceS (bess) --------------------------- "BGP based Multi-homing in Virtual Private LAN Service", Kireeti Kompella, Bhupesh Kothari, Wim Henderickx, Florin Balus, Jim Uttaro, 2025-06-16, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Wen Lin, John Drake, Ali Sajassi, 2023-10-09, The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single- active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user- controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. This document updates RFC8584 by modifying the definition of the DF Election Extended Community. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan, 2024-12-09, Ethernet VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multi-homing capabilities. Specifically, they support Single-Active and All- Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multi-homed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an Ethernet Segment by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or other entities, including MPLS Label Switched Paths (LSPs) or Pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vES). This draft list the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN. "Weighted Multi-Path Procedures for EVPN Multi-Homing", Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria, 2025-05-13, 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 Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, Eric Rosen, John Drake, Wen Lin, Jim Uttaro, Adam Simpson, 2025-02-04, Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end-to-end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. "Seamless Multicast Interoperability between EVPN and MVPN PEs", Ali Sajassi, Kesavan Thiruvenkatasamy, Samir Thoria, Ashutosh Gupta, Luay Jalil, 2025-03-02, 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. "Controller-based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk, Dante Pacella, Arkadiy Gulko, 2025-02-28, This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. "EVPN Port-Active Redundancy Mode", Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan, 2024-12-05, The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load-balancing. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'. "EVPN Network Layer Fault Management", Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake, 2025-04-22, This document specifies proactive, in-band network layer OAM (RFC 9062) mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN, RFC 7432bis) network. The mechanisms specified in this document use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol. "BGP Usage for SD-WAN Overlay Networks", Linda Dunbar, Ali Sajassi, John Drake, Basil Najem, Susan Hares, 2024-12-20, This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. "Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication", Rishabh Parekh, Clarence Filsfils, Mankamana Mishra, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang, 2025-02-02, A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes 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. "BGP MPLS-Based Ethernet VPN", Ali Sajassi, Luc Burdet, John Drake, Jorge Rabadan, 2025-03-18, This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates RFC8214 (Virtual Private Wire Service Support in Ethernet VPN). "Multicast Source Redundancy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Wen Lin, 2025-02-14, In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalable layer-2 and layer-3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate IP multicast traffic in the network, causing inefficiencies and increased overhead. This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate IP multicast traffic from redundant sources. The proposed mechanisms enhance EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies. "EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols", Luc Burdet, Patrice Brissette, Ali Sajassi, Praveen Maheshwari, Ishan Bhatt, 2025-03-03, 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. "Cumulative DMZ Link Bandwidth and load-balancing", MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, Reshma Das, 2025-01-02, The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor-level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers. "EVPN-VPWS Seamless Integration with L2VPN VPWS", Patrice Brissette, Wen Lin, Jorge Rabadan, Jim Uttaro, Bin Wen, 2025-05-09, 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. "Segment Routing over IPv6 Argument Signaling for BGP Services", Ketan Talaulikar, Syed Raza, Jorge Rabadan, Wen Lin, 2025-05-09, RFC9252 defines procedures and messages for BGP Overlay Services for Segment Routing over IPv6 (SRv6) including Layer 3 Virtual Private Network, Ethernet Virtual Private Network, and Global Internet Routing. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifiers advertisements for BGP Overlay Service routes associated with SRv6 Endpoint Behaviors that support arguments. "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Ali Sajassi, Jorge Rabadan, S. Pasupula, Lukas Krattiger, John Drake, 2025-05-07, This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. "Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks", Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin, 2025-03-03, 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. "Ethernet VPN Virtual Private Wire Services Gateway Solution", Jorge Rabadan, Senthil Sathappan, Vinod Prabhu, Wen Lin, Patrice Brissette, 2025-05-19, Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. "EVPN Fast Reroute", Luc Burdet, Patrice Brissette, Takuya Miyasaka, Jorge Rabadan, Yisong Liu, Changwang Lin, 2025-06-09, This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, Jeffrey Haas, 2025-06-04, This document describes an experimental optimization to BFD Authentication. It provides procedure where only important BFD state transitions require strong authentication and permits the majority of BFD Control Packets to use a less computationally intensive authentication mechanism. This enables BFD to scale better when there is a desire to use strong authentication. "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen, 2025-06-11, 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. "Meticulous Keyed ISAAC for BFD Optimized Authentication", Alan DeKok, Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, 2025-05-05, This document describes a new BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate 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 the "Up" state. Bit Indexed Explicit Replication (bier) --------------------------------------- "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow, 2025-05-05, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2025-02-11, This document defines a YANG data model that can be used to configure and manage devices supporting Bit Index Explicit Replication"(BIER). The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). "BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, Zhaohui Zhang, 2025-06-03, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. "PIM Signaling Through BIER Core", Hooman Bidgoli, Fengman Xu, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang, 2025-03-03, Consider large networks deploying traditional PIM multicast service. Typically, each portion of these large networks have their own mandates and requirements. It might be desirable to deploy BIER technology in some part of these networks to replace traditional PIM services. In such cases downstream PIM states need to be signaled over the BIER Domain toward the source. This document specifies the procedures to signal PIM Join and Prune messages through a BIER Domain using [RFC9739] , enabling the provisioning of traditional PIM services through a BIER Domain. These procedures are valid for forwarding PIM Join/Prune messages to the Source (SSM) or Rendezvous Point (ASM). "BIER Penultimate Hop Popping", Zhaohui Zhang, 2024-12-04, This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks. "A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh Sivakumar, chenhuanan, 2025-01-20, This document defines a YANG data module for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. "BIER Prefix Redistribute", Zheng Zhang, Bo Wu, Zhaohui Zhang, IJsbrand Wijnands, Yisong Liu, Hooman Bidgoli, 2025-02-23, This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. "M-LDP Signaling Through BIER Core", Hooman Bidgoli, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang, Eddie Leyton, 2025-02-05, Consider an end-to-end Multipoint LDP (mLDP) network, where it is desirable to deploy BIER in a segment of this network. It might be desirable to deploy BIER with minimal disruption to the mLDP network or a redesign of the network. This document describes a procedure needed for mLDP tunnels to be signaled over and stitched through a BIER core, allowing LDP routers to run traditional mLDP services through a BIER core. "BIER BFD", Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, Gyan Mishra, 2025-02-26, Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. "BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover", Zheng Zhang, Greg Mirsky, Quan Xiong, Yisong Liu, Huanan Li, 2025-03-27, This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. "Supporting BIER in IPv6 Networks (BIERin6)", Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra, 2025-03-02, BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. "BIER Fast Reroute (BIER-FRR)", Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra, 2025-06-06, This document describes BIER Fast Reroute (BIER-FRR) as a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. It enhances the resiliency of BIER by quickly rerouting BIER traffic in the event of a link or node failure. This ensures that multicast traffic continues to reach its intended destinations, thereby minimizing packet loss and service disruption. BIER-FRR is designed to integrate seamlessly with existing BIER operations without requiring per-flow state or additional signaling. The document suggests additional structures for BIER to hold information for backup forwarding entries and to enable them in case of detected failures. BIER-FRR can implement different protection levels, e.g., link protection or node protection, and different protection strategies. Tunnel-based BIER-FRR and LFA-based BIER-FRR are introduced as protection strategies and their implementation with the proposed extensions. A comparison highlights the differences between both approaches. Benchmarking Methodology (bmwg) ------------------------------- "Multiple Loss Ratio Search", Maciek Konstantynowicz, Vratko Polak, 2025-03-16, This document proposes extensions to RFC 2544 throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and enhance result repeatability and comparability. The primary reason for extending RFC 2544 is to address the challenges of evaluating and testing the data planes of software- based networking systems. To give users more freedom, MLRsearch provides additional configuration options such as allowing multiple short trials per load instead of one large trial, tolerating a certain percentage of trial results with higher loss, and supporting the search for multiple goals with varying loss ratios. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Tran Ngoc, Sridhar Rao, Jangwon Lee, Younghan Kim, 2025-03-16, 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", Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene, 2025-03-03, 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. Calendaring Extensions (calext) ------------------------------- "JSCalendar: Converting from and to iCalendar", Robert Stepanek, 2025-05-21, 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. "Calendar subscription upgrades", Michael Douglass, 2025-03-17, This specification updates RFC5545 to add the value DELETED to the STATUS property. This specification also adds values to the Preferences Registry defined in RFC7240 to add the subscribe-enhanced-get and limit preferences and to the link relations directory defined in RFC8288. "Task Extensions to iCalendar", Adrian Apthorp, Michael Douglass, 2025-03-17, The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has seen limited adoption and use, mainly for personal reminders and to-do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. "JSCalendar: A JSON Representation of Calendar Data", Neil Jenkins, Robert Stepanek, 2025-06-11, 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", Robert Stepanek, 2025-06-02, 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)"). "Protocol-Specific Profiles for JSContact", Robert Stepanek, Mario Loffredo, 2025-06-04, This document defines JSContact profiles, a named subsets of JSContact elements that are supported in context of a contact data exchange protocol or other use case. It aims to facilitate using JSContact in contexts where supporting all of JSContact semantics is not appropriate. Computing-Aware Traffic Steering (cats) --------------------------------------- "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Kehan Yao, Luis Contreras, Hang Shi, Shuai Zhang, Qing An, 2025-06-10, 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. "A Framework for Computing-Aware Traffic Steering (CATS)", Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake, 2025-06-11, 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", Kehan Yao, Hang Shi, Cheng Li, Luis Contreras, Jordi Ros-Giralt, 2025-03-03, 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 computing domain used for CATS. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Packed CBOR", Carsten Bormann, Mikolai Guetschow, 2025-05-12, 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 to 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 revision -15 is intended to serve as the input for the // 2025-05-14 CBOR interim meeting; it still has the tunables A/B/C // to be tuned. "CBOR Extended Diagnostic Notation (EDN)", Carsten Bormann, 2025-05-12, 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 -17 is // intended to fully address the WGLC comments. It is intended for // use as a reference document for the CBOR WG interim meeting on // 2025-05-14. "CDDL Module Structure", Carsten Bormann, Brendan Moran, 2025-03-03, At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. "CBOR Common Deterministic Encoding (CDE)", Carsten Bormann, 2025-05-12, CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines the term "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. "External References to Values in CBOR Diagnostic Notation (EDN)", Carsten Bormann, 2024-12-29, The Concise Binary Object Representation (CBOR, RFC 8949) 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 diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. Common Control and Measurement Plane (ccamp) -------------------------------------------- "A YANG Data Model for Optical Transport Network Topology", Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios, 2024-11-07, This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. "A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths", Haomian Zheng, Italo Busi, Sergio Belotti, Victor Lopez, Yunbin Xu, 2025-06-04, This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. "A YANG Data Model for Flexi-Grid Optical Networks", Universidad de Madrid, Daniel Burrero, Daniel King, Young Lee, Haomian Zheng, 2025-03-17, This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli, 2024-04-11, This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). "A YANG data model to manage configurable DWDM optical interfaces", Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer, 2025-02-12, 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 Optical Impairment-aware Topology", Dieter Beller, Esther Le Rouzic, Sergio Belotti, Gabriele Galimberti, Italo Busi, 2025-04-11, 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 WSON, while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks. "A YANG Data Model for Transport Network Client Signals", Haomian Zheng, Aihua Guo, Italo Busi, Anton Snitser, Chaode Yu, 2025-02-04, A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. "Common YANG Data Types for Layer 1 Networks", Haomian Zheng, Italo Busi, 2024-02-23, This document defines a collection of common common data types, identities, and groupings in the YANG data modeling language. These derived common common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. "A YANG Data Model for Ethernet TE Topology", Chaode Yu, Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2025-04-14, 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. "Framework and Data Model for OTN Network Slicing", Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu, 2025-01-10, The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. "Common YANG Data Types for Layer 0 Networks", Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo, 2025-06-06, 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. "YANG Data Model for FlexE Management", Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu, 2025-06-02, This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). "A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN)", Italo Busi, Aihua Guo, Sergio Belotti, 2025-04-14, 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. "YANG Data Models for requesting Path Computation in WDM Optical Networks", Italo Busi, Aihua Guo, Sergio Belotti, 2025-02-28, This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments 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. "A YANG Data Model for WDM Tunnels", Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero, 2025-04-23, 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). "Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with programmable pluggables under ACTN Framework", Oscar de Dios, Jean-Francois Bouquier, Julien Meuric, Gyan Mishra, Gabriele Galimberti, 2025-04-29, This document provides general overarching guidelines for control and management of packet over optical converged networks with programmable pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on programmable pluggables. The document provides a gap analysis to solve the use cases. "Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks", 谭艳霞, XingZhao, Chaode Yu, Daniel King, Adrian Farrel, 2025-05-28, Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. Congestion Control Working Group (ccwg) --------------------------------------- "BBR Congestion Control", Neal Cardwell, Ian Swett, Joseph Beshay, 2025-02-28, 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. "Increase of the Congestion Window when the Sender Is Rate-Limited", Michael Welzl, Tom Henderson, Gorry Fairhurst, Mohit Tahiliani, 2025-03-05, 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. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition", Nir Sopher, Ori Finkelman, Sanjay Mishra, Jay Robertson, Alan Arolovitch, 2025-02-25, 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. "CDNI Capacity Capability Advertisement Extensions", Andrew Ryan, Ben Rosenblum, Nir Sopher, 2024-12-12, The Content Delivery Networks Interconnection (CDNI) Capacity Capability Advertisement Extensions define a set of additional Capability Objects that provide information about current downstream CDN (dCDN) utilization and specified usage limits to the delegating upstream CDN (uCDN) in order to inform traffic delegation decisions. This document supplements the CDNI Capability Objects, defined in RFC 8008 as part of the Footprints & Capabilities Advertisement Interface (FCI), with two additional Capability Objects: FCI.CapacityLimits and FCI.Telemetry. "CDNI Cache Control Metadata", Will Power, Glenn Goldstein, 2025-01-03, This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. "CDNI Edge Control Metadata", Alfonso Siloniz, Glenn Goldstein, 2025-03-03, This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. "CDNI Protected Secrets Metadata", Ben Rosenblum, Glenn Goldstein, 2025-03-03, This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. "CDNI Logging Extensions", Ben Rosenblum, Omar Ramadan, Kenton Seward, 2025-01-07, This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. "Content Delivery Network Interconnection (CDNI) Named Footprints", Alan Arolovitch, 2025-01-07, Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document extends the Footprint & Capabilities Advertisement Interface (FCI) defined in RFC8008, to allow advertising of named footprint objects, that can be referenced in a consistent manner from Metadata Interface (MI), also defined in RFC8006, as well as from the FCI itself as well as additional interfaces in the Open Caching architecture. This document also supplements the CDNI Metadata Footprint Types defined in RFC8006 and modifies the CDNI operation as described in RFC7336. "CDNI Client Access Control Metadata", Pankaj Chaudhari, Glenn Goldstein, Will Power, Arnon Warshavsky, 2025-01-03, This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "Matroska Media Container Codec Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2024-12-15, This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. "Matroska Media Container Tag Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2025-05-30, This document defines the Matroska multimedia container tags, namely the tag names and their respective semantic meaning. Crypto Forum (cfrg) ------------------- "KangarooTwelve and TurboSHAKE", Benoit Viguier, David Wong, Gilles Van Assche, Quynh Dang, Joan Daemen, 2025-02-21, This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. "Additional Parameter sets for HSS/LMS Hash-Based Signatures", Scott Fluhrer, Quynh Dang, 2025-02-12, This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "CPace, a balanced composable PAKE", Michel Abdalla, Bjoern Haase, Julia Hesse, 2025-04-16, 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. "Usage Limits on AEAD Algorithms", Felix Guenther, Martin Thomson, Christopher Wood, 2025-04-08, An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. "The OPAQUE Augmented PAKE Protocol", Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood, 2024-11-21, This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Verifiable Distributed Aggregation Functions", Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann, 2025-01-10, 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). "Key Blinding for Signature Schemes", Frank Denis, Edward Eaton, Tancrede Lepoint, Christopher Wood, 2025-03-17, This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. "The AEGIS Family of Authenticated Encryption Algorithms", Frank Denis, Samuel Lucas, 2025-02-17, 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. "Hedged ECDSA and EdDSA Signatures", John Mattsson, Erik Thormarker, Sini Ruohomaa, 2025-03-03, Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. "The BBS Signature Scheme", Tobias Looker, Vasilis Kalos, Andrew Whitehead, Mike Lodder, 2025-03-03, This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. "Deterministic Nonce-less Hybrid Public Key Encryption", Dan Harkins, 2025-03-03, 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. "Implementation Guidance for the PKCS #1 RSA Cryptography Specification", Alicja Kario, 2025-02-20, This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. "Partially Blind RSA Signatures", Ghous Amjad, Scott Hendrickson, Christopher Wood, Kevin Yeo, 2025-04-01, 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. "Hybrid PQ/T Key Encapsulation Mechanisms", Deirdre Connolly, 2025-02-25, This document defines generic techniques to achive hybrid post- quantum/traditional (PQ/T) key encapsulation mechanisms (KEMs) from post-quantum and traditional component algorithms that meet specified security properties. It then uses those generic techniques to construct several concrete instances of hybrid KEMs. "Blind BBS Signatures", Vasilis Kalos, Greg Bernstein, 2025-03-03, This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. 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/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. "BBS per Verifier Linkability", Vasilis Kalos, Greg Bernstein, 2025-03-03, The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. "Kemeleon Encodings", Felix Guenther, Douglas Stebila, Shannon Veitch, 2025-04-11, This document specifies Kemeleon encoding algorithms for encoding ML- KEM encapsulation keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of encapsulation keys and ciphertexts, relying on module LWE assumptions. This document specifies a number of variants of these encodings, with differing failure rates, output sizes, and performance profiles. Computing in the Network Research Group (coinrg) ------------------------------------------------ "Use Cases for In-Network Computing", Ike Kunze, Klaus Wehrle, Dirk Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio, 2024-12-04, Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. It is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard. Constrained RESTful Environments (core) --------------------------------------- "A publish-subscribe architecture for the Constrained Application Protocol (CoAP)", Jaime Jimenez, Michael Koster, Ari Keranen, 2025-02-28, This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. "CoAP Management Interface (CORECONF)", Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann, 2025-05-06, This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Marco Tiloca, Goeran Selander, Francesca Palombini, John Mattsson, Rikard Hoeglund, 2025-03-16, This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. "Constrained Resource Identifiers", Carsten Bormann, Henk Birkholz, 2025-03-20, 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 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –22 addresses a few remaining post-WGLC nits. "Group Communication for the Constrained Application Protocol (CoAP)", Esko Dijk, Marco Tiloca, 2025-02-24, This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. "Observe Notifications as CoAP Multicast Responses", Marco Tiloca, Rikard Hoeglund, Christian Amsuess, Francesca Palombini, 2025-03-03, The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and 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 a 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 a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. "Conditional Query Parameters for CoAP Observe", Bill Silverajan, Michael Koster, Alan Soloway, 2025-03-16, This specification defines Conditional Notification and Control Query Parameters compatible with CoAP Observe (RFC7641). "YANG-CBOR: Allocating SID ranges for PEN holders", Carsten Bormann, 2025-03-19, YANG-CBOR, RFC 9254 defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 defines ways to allocate these SIDs on the basis of IANA registries. The present specification uses these SID allocation mechanisms to allocate ranges with 100 000 63-bit SIDs each for each of the first 1 000 000 holders of IANA-registered Private Enterprise Numbers (PENs), as well as ranges with 10 000 32-bit SIDs each for each of the first 100 000 holders. "Key Update for OSCORE (KUDOS)", Rikard Hoeglund, Marco Tiloca, 2025-03-03, This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. "Attacks on the Constrained Application Protocol (CoAP)", John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess, 2024-12-22, Being able to securely retrieve information from sensors and control actuators while providing guards against distributed denial-of- service (DDoS) attacks are key requirements for CoAP deployments. To that aim, a security protocol (e.g., DTLS, TLS, or OSCORE) can be enabled to ensure secure CoAP operation, including protection against many attacks. This document identifies a set of known CoAP attacks and shows that simply using CoAP with a security protocol is not always enough for secure operation. Several of the identified attacks can be mitigated with a security protocol providing confidentiality and integrity combined with the solutions specified in RFC 9175. "CoAP Transport Indication", Christian Amsuess, Martine Lenders, 2025-03-03, The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. "DNS over CoAP (DoC)", Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, 2025-04-03, This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). "Key Usage Limits for OSCORE", Rikard Hoeglund, Marco Tiloca, 2025-01-08, Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. "Constrained Application Protocol (CoAP) Performance Measurement Option", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fabio Bulgarella, Yongqing Zhu, 2025-04-04, 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. "OSCORE-capable Proxies", Marco Tiloca, Rikard Hoeglund, 2025-03-03, Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. "Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk, 2025-03-03, This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client typically over unicast, and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. "Identifier Update for OSCORE", Rikard Hoeglund, Marco Tiloca, 2025-01-08, 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. "ALPN ID Specification for CoAP over DTLS", Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch, 2025-04-01, This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services. "Constrained Application Protocol (CoAP): Corrections and Clarifications", Carsten Bormann, 2024-12-18, RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. "Update to the IANA CoAP Content-Formats Registration Procedures", Thomas Fossati, Esko Dijk, 2025-05-09, This document updates RFC7252 regarding the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation. "YANG-CBOR: Allocating SID ranges for PEN holders", Carsten Bormann, 2025-04-24, YANG-CBOR, RFC 9254 defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 defines ways to allocate these SIDs on the basis of IANA registries. The present specification uses these SID allocation mechanisms to allocate ranges with 100 000 63-bit SIDs each for each of the first 1 000 000 holders of IANA-registered Private Enterprise Numbers (PENs), as well as ranges with 10 000 32-bit SIDs each for each of the first 100 000 holders. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Encoded X.509 Certificates (C509 Certificates)", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2025-03-03, This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include CBOR certificates. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. "Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)", Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade, 2025-06-04, 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 works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. This document defines the use of the HPKE with COSE. "Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE", Tobias Looker, Michael Jones, 2025-01-18, This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tplooker/draft-ietf-cose-bls-key-representations. "ML-DSA for JOSE and COSE", Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans, 2025-06-12, This document describes 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 FIPS 204. "COSE Receipts", Orie Steele, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, 2025-05-11, COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. "COSE Header parameter for RFC 3161 Time-Stamp Tokens", Henk Birkholz, Thomas Fossati, Maik Riechert, 2025-06-12, This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure in COSE-based protocols. "COSE Hash Envelope", Orie Steele, Steve Lasker, Henk Birkholz, 2025-03-28, 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. DANE Authentication for Network Clients Everywhere (dance) ---------------------------------------------------------- "TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor Dukhovni, 2025-06-13, The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. "TLS Extension for DANE Client Identity", Shumon Huque, Viktor Dukhovni, 2025-06-13, This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. "An Architecture for DNS-Bound Client and Sender Identities", Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson, 2025-04-22, 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. DNS Delegation (deleg) ---------------------- "Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements", tale, Edward Lewis, Jim Reid, Tim Wicinski, 2025-04-06, 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. "Extensible Delegation for DNS", Tim April, Petr Spacek, Ralf Weber, tale, 2025-05-06, A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking (DetNet) Topology YANG Model", Xuesong Geng, Mach Chen, Zhenqiang Li, Reshad Rahman, 2025-03-02, This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). "Reliable and Available Wireless (RAW) Technologies", Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas, 2025-04-15, This document surveys the short and middle range radio technologies that are suitable to provide a Deterministic Networking / Reliable and Available Wireless (RAW) service over, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of its time of publication. The studied technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). "Deterministic Networking (DetNet) Controller Plane Framework", Andrew Malis, Xuesong Geng, Mach Chen, Balazs Varga, Carlos Bernardos, 2025-05-16, This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. "Reliable and Available Wireless Architecture", Pascal Thubert, 2025-06-10, Reliable and Available Wireless (RAW) extends the reliability and availability of DetNet to networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet service sublayer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. "Requirements for Scaling Deterministic Networks", Peng Liu, Yizhou Li, Toerless Eckert, Quan Xiong, Jeong-dong Ryoo, zhushiyin, Xuesong Geng, 2025-06-01, Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, a great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. "Dataplane Enhancement Taxonomy", Jinoo Joung, Xuesong Geng, Shaofu Peng, Toerless Eckert, 2025-03-02, This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters, 2025-06-04, This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). "DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support", Claudio Porfiri, Suresh Krishnan, Jari Arkko, Mirja Kuehlewind, 2025-06-02, This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4- over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in an intermediate node rather than the client. Dispatch (dispatch) ------------------- "Media Type Registration for Protocol Buffers", Murray Kucherawy, Warren Kumari, Rob Sloan, 2025-06-03, This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Todd Herr, John Levine, 2025-04-04, This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting", Alex Brotman, 2025-03-17, Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record. Distributed Mobility Management (dmm) ------------------------------------- "Mobility-aware Transport Network Slicing for 5G", Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras, 2025-05-21, 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. "Architecture Discussion on SRv6 Mobile User plane", Teppei Kamata, Francois Clad, Pablo Camarillo, Zafar Ali, Luay Jalil, Weiqiang Cheng, Miya Kohno, 2025-03-01, This document describes the solution approach and its architectural benefits of transforming mobile session information into routing information, leveraging segment routing capabilities, and operating within the IP routing paradigm. "Mobile User Plane Architecture for Distributed Mobility Management", Satoru Matsushima, Katsuhiro Horiba, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Jakub Horn, 2025-05-30, 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. Domain Name System Operations (dnsop) ------------------------------------- "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Willem Toorop, 2025-02-27, This document recommends improved DNS resolver behavior with respect to the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution. 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. "Domain Control Validation using DNS", Shivan Sahib, Shumon Huque, Paul Wouters, Erik Nygren, Tim Wicinski, 2025-03-03, 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. "Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC", Benjamin Schwartz, Robert Evans, 2025-03-03, Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. "Structured Error Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil Cook, Mohamed Boucadair, 2025-05-05, DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. "Compact Denial of Existence in DNSSEC", Shumon Huque, Christian Elmerot, Olafur Gudmundsson, 2025-02-27, This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFC 4034 and 4035. "Clarifications on CDS/CDNSKEY and CSYNC Consistency", Peter Thomassen, 2025-04-09, 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, 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, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) can query these records from the child and, after validation, use them to update the parent-side RRsets of the delegation. This document specifies that when performing such queries, parent- side entities MUST 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. "Generalized DNS Notifications", Johan Stenstam, Peter Thomassen, John Levine, 2025-03-19, This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, to allow triggering other types of actions via the DNS that were previously lacking a trigger mechanism. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ). To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the new DSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. "Deprecate usage of ECC-GOST within DNSSEC", Wes Hardaker, Warren Kumari, 2025-06-03, This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") within DNSSEC. RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933 by deprecating the use of ECC-GOST. "DNSSEC Cryptographic Algorithm Recommendation Update Process", Wes Hardaker, Warren Kumari, 2025-06-04, The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC8624 to an IANA registry. This is done both to allow the list of requirements to be more easily updated, and to allow the list to be more easily referenced. Future extensions to this registry can be made under new, incremental update RFCs. This document also incorporates the revised IANA DNSSEC considerations from RFC9157. The document does not change the status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC8624; that is the work of future documents. "Deprecating the use of SHA-1 in DNSSEC signature algorithms", Wes Hardaker, Warren Kumari, 2025-06-03, This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms. "Greasing Protocol Extension Points in the DNS", Shumon Huque, Mark Andrews, 2025-03-02, Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. 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/ietf-wg-dnsop/draft-ietf-dnsop-grease. "DNS IPv6 Transport Operational Guidelines", Momoka Yamamoto, Tobias Fiebig, 2025-04-07, This memo provides guidelines and documents Best Current Practice for operating authoritative DNS servers as well as recursive and stub DNS resolvers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance on recursive DNS resolver selection for stub DNS resolvers. This document obsoletes RFC3901. (if approved) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "DNS Multiple QTYPEs", Ray Bellis, 2025-03-20, This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). "Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option", Ted Lemon, Esko Dijk, 2025-04-04, 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. Drone Remote ID Protocol (drip) ------------------------------- "DRIP Entity Tags in the Domain Name System", Adam Wiethuechter, Jim Reid, 2025-06-05, This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. "The DRIP DET public Key Infrastructure", Robert Moskowitz, Stuart Card, 2025-04-22, 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. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle-in-Bundle Encapsulation", Scott Burleigh, Alberto Montilla, Joshua Deaton, Carlo Caini, 2025-03-15, This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called Bundle Retransmission Methods (BRM). This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol (version 6) specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. "Bundle Protocol Security (BPSec) COSE Context", Brian Sipos, 2025-06-03, 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. "DTNMA Application Resource Identifier (ARI)", Edward Birrane, Emery Annis, Brian Sipos, 2025-05-28, 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. "DTNMA Application Management Model (AMM) and Data Models", Edward Birrane, Brian Sipos, Justin Ethier, 2025-05-27, This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. "DTNMA Application Data Model (ADM) YANG Syntax", Edward Birrane, Brian Sipos, Justin Ethier, 2025-02-18, This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. "DTNMA Asynchronous Management Protocol (AMP)", Edward Birrane, Brian Sipos, 2025-05-28, This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport binding for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing remote management of resource constrained devices possibly over challenged networks. "Bundle Protocol Endpoint ID Patterns", Brian Sipos, 2025-05-13, 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. "Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2", Brian Sipos, Joshua Deaton, 2025-05-12, This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of RFC7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unreliable transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. "BPv7 Secure Advertisement and Neighborhood Discovery (SAND)", Brian Sipos, Joshua Deaton, 2025-01-14, This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). Detecting Unwanted Location Trackers (dult) ------------------------------------------- "DULT Threat Model", Maggie Delano, Jessica Lowell, Shailesh Prabhu, 2025-03-01, Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner 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 location trackers must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, will define what is in and out of scope for the unwanted location tracking protocols, and will provide some design considerations for implementation of protocols to detect unwanted location tracking. "Finding Tracking Tags", Christine Fossaceca, Eric Rescorla, 2025-06-06, Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. This document defines the protocol by which devices report tags they have seen and by which owners look up their location. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "A LoST extension to return complete and similar location info", Brian Rosen, Roger Marshall, Jeff Martin, 2022-03-04, This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a . This extension supports two use cases: First, when the input location is valid but lacks some Civic Address elements, the LoST server can provide a completed form. Second, when the input location is invalid, the LoST server can identify one or more feasible ("similar") locations. This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222 or another profile whose definition provides instructions concerning its use with this extension. "Validation of Locations Around a Planned Change", Brian Rosen, 2025-01-06, 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 request to allow a LoST client to request validation as of a specified date. It adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. It also adds a separate interface to a LoST server that allows a client to poll for planned changes. Additionally, this document provides a conventional XML schema for LoST, as a backwards compatible alternative to the RelaxNG schema in RFC5222. "Emergency Registries", Brian Rosen, Brandon Abley, 2025-01-02, Multiple emergency services standards organizations are developing specifications based on IETF emergency calling and other IETF protocols. There is a desire among these organizations to use common registries, not tied to a particular country or national Standards Development Organization (SDO), in the long term pursuit of a single worldwide standard. This document asks IANA to create a set of registries and provides processes for expanding the set and populating them. Revision of core Email specifications (emailcore) ------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 2025-04-28, This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. "Applicability Statement for IETF Core Email Protocols", John Klensin, Kenneth Murchison, 2025-03-18, 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. Open Issues * #92 - CNAME handling in "5.1. Locating the Target Host" (https://github.com/ietf-wg-emailcore/emailcore/issues/92): Per IETF 120, Klensin to propose text. * #113 - More explanation of the advantages of transport and encryption between SMTP systems... probably in the A/S (https://github.com/ietf-wg-emailcore/emailcore/issues/113): What, if anything, needs to be done here? "Internet Message Format", Pete Resnick, 2024-06-13, This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. EAP Method Update (emu) ----------------------- "Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)", Owen Friel, Dan Harkins, 2025-02-06, This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. "Tunnel Extensible Authentication Protocol (TEAP) Version 1", Alan DeKok, 2025-05-28, This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. "Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC)", Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, Francisco Lopez, 2025-06-04, 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. "The eap.arpa domain and EAP provisioning", Alan DeKok, 2025-06-04, This document defines the eap.arpa domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers which use the Network Access Identifier (NAI) format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140. "EAP-FIDO", Jan-Frederik Rieckers, Stefan Winter, 2025-03-03, This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. 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-emu-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/. Global Routing Operations (grow) -------------------------------- "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Alexander Azimov, 2025-02-25, Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. "BMP v4: TLV Support for BGP Monitoring Prtoocol (BMP) Route Monitoring and Peer Down Messages", Paolo Lucente, Yunan Gu, 2025-02-24, 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. "AS Path Prepending", Mike McBride, Doug Madory, Jeff Tantsura, Robert Raszuk, Hongwei Li, Jakob Heitz, Gyan Mishra, 2025-04-23, 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. "Support for Enterprise-specific TLVs in the BGP Monitoring Protocol", Paolo Lucente, Yunan Gu, 2025-01-17, Message types defined by the BGP Monitoring Protocol (BMP) do provision for data in TLV - Type, Length, Value - format, either in the shape of a TLV message body, ie. Route Mirroring and Stats Reports, or optional TLVs at the end of a BMP message, ie. Peer Up and Peer Down. However the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. In this document we introduce an Enterprise Bit, or E-bit, for such purpose. "Near Real Time Mirroring (NRTM) version 4", Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras, 2025-05-14, This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. "BMP YANG Module", Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, Narasimha Prasad, 2025-06-12, This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). "BMP Extension for Path Status TLV", Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf, 2025-04-23, The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP path information, which is is conveyed through BMP Route Monitoring (RM) messages. This document specifies a BMP extension to convey the status of a path after being processed by the BGP process. "Logging of routing events in BGP Monitoring Protocol (BMP)", Paolo Lucente, Camilo Cardona, 2025-03-03, The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis. "A YANG Data Model for BGP Communities", Martin Pels, 2025-03-24, 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. "Definition For New BGP Monitoring Protocol (BMP) Statistics Types", Mukul Srivastava, Yisong Liu, Changwang Lin, Jinming Li, 2025-04-24, 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). "Updated BGP Operations and Security", Tobias Fiebig, Nick Hilliard, 2025-04-15, 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. To this end, the document describes the security requirements and goals when operating BGP for exchanging routing information with other networks. The document explicitly does not focus on specific technical implementations and requirements. Operators are advised to consult documentation and contemporary informational documents concerning methods to ensure that these properties are sufficiently ensured in their network. "Guidance to Avoid Use of BGP Extended Communities at Internet Exchange Route Servers", Job Snijders, Stavros Konstantaras, Mo Shivji, 2025-06-01, This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. This document updates RFC 7948. "TCP-AO Protection for BGP Monitoring Protocol (BMP)", Hemant Sharma, Jeffrey Haas, 2025-02-23, This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. 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/hmntsharma/draft-hmntsharma-bmp-tcp-ao. "BMP Loc-RIB: Peer address", Pierre Francois, Maxence Younsi, Paolo Lucente, 2025-03-16, 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. "Currently Used Terminology in Global Routing Operations", Tobias Fiebig, Wolfgang Tremmel, 2025-04-09, 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", Tobias Fiebig, 2025-04-09, 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. Heuristics and Algorithms to Prioritize Protocol deploYment (happy) ------------------------------------------------------------------- "Happy Eyeballs Version 3: Better Connectivity Using Concurrency", Tommy Pauly, David Schinazi, Nidhi Jaju, Kenichi Ishibashi, 2025-04-07, 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. HPKE Publication, Kept Efficient (hpke) --------------------------------------- "Hybrid Public Key Encryption", Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, Christopher Wood, 2025-06-01, This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE", Richard Barnes, 2025-06-01, Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attack by a quantum computer. Building Blocks for HTTP APIs (httpapi) --------------------------------------- "RateLimit header fields for HTTP", Roberto Polli, Alex Ruiz, Darrel Miller, 2025-03-17, This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. "The Idempotency-Key HTTP Header Field", Jayadeba Jena, Sanjay Dalal, 2025-02-25, The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. "REST API Media Types", Roberto Polli, 2025-04-26, This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. "HTTP Link Hints", Mark Nottingham, 2025-05-18, This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. "HTTP Problem Types for Digest Fields", Marius Kleidl, Lucas Pardue, Roberto Polli, 2025-06-11, This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. "API Keys and Privacy", Rich Salz, Mike Bishop, Marius Kleidl, 2025-06-03, Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. HTTP (httpbis) -------------- "Cookies: HTTP State Management Mechanism", Steven Bingler, Mike West, John Wilander, 2025-03-17, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. "The HTTP QUERY Method", Julian Reschke, James Snell, Mike Bishop, 2025-05-19, This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. "Resumable Uploads for HTTP", Marius Kleidl, Guoye Zhang, Lucas Pardue, 2025-06-04, Data transfer using the Hypertext Transfer Protocol (HTTP) is often interrupted by 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. "Template-Driven HTTP CONNECT Proxying for TCP", Benjamin Schwartz, 2025-06-11, TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. "Compression Dictionary Transport", Patrick Meenan, Yoav Weiss, 2024-08-28, This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol. "HTTP Cache Groups", Mark Nottingham, 2025-05-16, This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored response with one or more strings. "Security Considerations for Optimistic Protocol Transitions in HTTP/1.1", Benjamin Schwartz, 2025-06-11, In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues. "No-Vary-Search", Domenic Denicola, Jeremy Roman, 2025-03-20, This specification defines a proposed HTTP header field for changing how URL search parameters impact caching. "HTTP Unencoded Digest", Lucas Pardue, Mike West, 2025-02-07, The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. "The HTTP Wrap Up Capsule", David Schinazi, Lucas Pardue, 2025-01-08, HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. "Incremental HTTP Messages", Kazuho Oku, Tommy Pauly, Martin Thomson, 2025-04-29, This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. "Cookies: HTTP State Management Mechanism", Anne van Kesteren, Johann Hofmann, 2025-05-14, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Applicability of Interfaces to Network Security Functions to Network-Based Security Services", Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares, Diego Lopez, 2025-04-03, This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. "I2NSF Consumer-Facing Interface YANG Data Model", Jaehoon Jeong, Chaehong Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2023-05-15, This document describes a YANG data model of the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. This document defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. The YANG data model is based on the "Event-Condition-Action" (ECA) policy defined by a capability YANG data model for I2NSF. The YANG data model enables different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain (e.g., user group). "I2NSF Network Security Function-Facing Interface YANG Data Model", Jinyong Kim, Jaehoon Jeong, J., PARK, Susan Hares, Qiushi Lin, 2022-06-01, This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework. "I2NSF Capability YANG Data Model", Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, Qiushi Lin, 2022-05-23, This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. "I2NSF Registration Interface YANG Data Model for NSF Capability Registration", Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J., PARK, 2023-05-10, This document defines a YANG data model for the Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of this data model is to support NSF capability registration and query via I2NSF Registration Interface. "I2NSF NSF Monitoring Interface YANG Data Model", Jaehoon Jeong, Patrick Lingga, Susan Hares, Liang Xia, Henk Birkholz, 2022-06-01, This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model. Internet Architecture Board (iab) --------------------------------- "IAB AI-CONTROL Workshop Report", Mark Nottingham, Suresh Krishnan, 2025-05-13, The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work. 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/intarchboard/draft-iab-ai-control-report. "Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)", Wes Hardaker, Dhruv Dhody, 2025-05-19, The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535 identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. Internet Congestion Control (iccrg) ----------------------------------- "rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP", Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen Balasubramanian, 2025-02-03, This document specifies rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). "LEDBAT++: Congestion Control for Background Traffic", Praveen Balasubramanian, Osman Ertugay, Daniel Havey, Marcelo Bagnulo, 2025-02-13, This memo describes LEDBAT++, a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. LEDBAT++ has been implemented as a TCP congestion control algorithm in the Windows operating system. LEDBAT++ has been deployed in production at scale on a variety of networks and been experimentally verified to achieve the original stated goals of LEDBAT. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). Information-Centric Networking (icnrg) -------------------------------------- "File-Like ICN Collections (FLIC)", Christian Tschudin, Christopher Wood, Marc Mosko, David Oran, 2025-03-03, This document describes how to encode an application data objet into a structured _manifest_ using Information Centric Networking (ICN) data objects, creating a File-Like ICN Collection (FLIC). The manifest is an "index table" of objects that make up the manifest itself and the application data. It records the hash value (content object hash) of each item so a consumer using the manifest may request each piece by a complete hash name. The manifest is hierarchical and may be encoded into realtively small ICN objects to fit within network MTU sizes. FLIC has several methods to guide a consumer in constructing appropriate Interest names based on the manifest. It also supports encryption of the manifest data. FLIC may be used in CCNx or Named Data Networking, or other ICNs. "Reflexive Forwarding for CCNx and NDN Protocols", David Oran, Dirk KUTSCHER, Hitoshi Asaeda, Ken Calvert, 2025-03-15, Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. "CCNx Content Object Chunking", Marc Mosko, Hitoshi Asaeda, 2025-03-16, This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. Inter-Domain Routing (idr) -------------------------- "BGP Link Bandwidth Extended Community", Prodosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani, 2025-05-27, This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang, 2025-03-30, This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. "BGP Community Container Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Bruno Decraene, Shane Amante, Paul Jakma, 2025-03-17, Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. This document defines a new encoding that enhances and simplifies what can be accomplished with BGP communities. This specification's most important addition is the ability to specify and advertise an operator's parameters for execution. It also provides an extensible platform for any future community encoding requirements. "Registered Wide BGP Community Values", Robert Raszuk, Jeffrey Haas, 2025-03-17, Communicating various routing policies via route tagging plays an important role in external BGP [RFC4271] peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities [RFC1997]. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2025-06-06, This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. "BGP-LS Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, Changwang Lin, 2025-02-11, This document describes the process to distribute Border Gateway Protocol- Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems. This document defines a new type within the BGP-LS NLRI for a Stub Link and three new type-length- values (TLVs) for BGP-LS Link descriptor. These additions to BGP-LS let Software Definition Network (SDN) controllers retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu, 2025-01-05, This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode". "SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS", Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar, 2025-04-16, 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", Cheng Li, Yongqing Zhu, Ahmed El Sawaf, Zhenbin Li, 2025-04-03, 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. "Signaling Maximum Transmission Unit (MTU) using BGP-LS", Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair, 2025-03-21, Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture and IPv6 architecture, with a new type of routing header. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path MTU of SR tunnel. However, SR uses the IGP as the routing protocol and does not support the negotiation of the Path MTU. BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This document specifies the extensions to BGP-LS to carry MTU information of link. The centralized controller (PCE/SDN) calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. "BGP SR Policy Extensions to Enable IFIT", Fengwei Qin, Hang Yuan, Shunxing Yang, Tianran Zhou, Giuseppe Fioccola, 2025-04-18, 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 UPDATE for SD-WAN Edge Discovery", Linda Dunbar, Susan Hares, Kausik Majumdar, Robert Raszuk, Venkit Kasiviswanathan, 2025-05-23, The document describes the BGP mechanisms for SD-WAN (Software Defined Wide Area Network) edge node attribute discovery. These mechanisms include a new tunnel type and sub-TLVs for the BGP Tunnel- Encapsulation Attribute [RFC9012] and set of NLRI (network layer reachability information) for Software-Defined Wide-Area Network (SD- WAN) underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turn propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. "BGP Flow Specification for SRv6", Zhenbin Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, Shunwan Zhuang, 2025-05-12, This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. "Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs)", Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li, 2025-06-13, An 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, which provide advanced features such as guaranteed resources, bounded latency or jitter to meet specific customer connectivity requirements. When Segment Routing (SR) is used for building 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. In some network scenarios, each NRP can be associated with a unique logical network topology. When a centralized network controller is used for NRP-specific constraint-based path computation, especially when an NRP spans multiple IGP areas or multiple Autonomous Systems (ASes), BGP-LS is needed to advertise the NRP topology and associated resource information to the network controller. This document describes a mechanism to distribute the information of SR based NRPs using BGP-LS with MT. "Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP", Giuseppe Fioccola, Ran Pang, Subin Wang, Bruno Decraene, Shunwan Zhuang, Haibo Wang, 2025-04-23, 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. "BGP Color-Aware Routing (CAR)", Dhananjaya Rao, Swadesh Agrawal, 2025-02-20, This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. "BGP Classful Transport Planes", Kaliraj Vairavakkalai, Natrajan Venkataraman, 2025-02-28, This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") procedures and follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") NLRI encoding is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. "Traffic Steering using BGP FlowSpec with SR Policy", Jiang Wenying, Yisong Liu, Shunwan Zhuang, Gyan Mishra, Shuanglong Chen, 2025-01-06, BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. "BGP Next Hop Dependent Characteristics Attribute", Bruno Decraene, John Scudder, Kireeti Kompella, MOHANTY Satya, Bin Wen, Kevin Wang, Serge Krier, 2025-03-30, 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. This specification also 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. "BGP Extension for 5G Edge Service Metadata", Linda Dunbar, Kausik Majumdar, Cheng Li, Gyan Mishra, Zongpeng Du, 2025-04-28, This draft describes a new Edge Metadata Path Attribute and some Sub- TLVs for egress routers to advertise the Edge Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE). "VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Jie Dong, 2025-06-04, This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. "BGP Flowspec for IETF Network Slice Traffic Steering", Jie Dong, Ran Chen, Subin Wang, Jiang Wenying, 2025-05-08, BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic Flow Specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be performed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). "Advertisement of Segment Routing Policies using BGP Link-State", Stefano Previdi, Ketan Talaulikar, Jie Dong, Hannes Gredler, Jeff Tantsura, 2025-03-06, This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. "BGP Extension for SR-MPLS Entropy Label Position", Yao Liu, Shaofu Peng, 2025-04-22, This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. "Segment Routing Segment Types Extensions for BGP SR Policy", Ketan Talaulikar, Clarence Filsfils, Stefano Previdi, Paul Mattes, Dhanendra Jain, 2025-02-20, This document specifies the signaling of additional Segment Routing Segment Types for signaling of Segment Routing (SR) Policies in BGP using SR Policy Subsequent Address Family Identifier. "BGP SR Policy Extensions for Network Resource Partition", Jie Dong, Zhibo Hu, Ran Pang, 2025-03-03, 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. "BGP SR Policy Extensions for Segment List Identifier", Changwang Lin, Weiqiang Cheng, Yao Liu, Ketan Talaulikar, Mengxiao Chen, 2025-03-27, 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 candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. "BGP SR Policy Extensions for metric", KaZhang, Jie Dong, Ketan Talaulikar, 2024-12-29, SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain, 2025-02-06, A Segment Routing (SR) Policy is an ordered list of segments (also referred to as instructions) that define a source-routed policy. An SR Policy consists of one or more candidate paths, each comprising one or more segment lists. A headend can be provisioned with these candidate paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP. This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths. Furthermore, this document updates RFC9012 by extending the Color Extended Community to support additional steering modes over SR Policy. "MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement", Chongfeng Xie, Guozhen Dong, Xing Li, Guoliang Han, Zhongfeng Guo, 2025-05-14, This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. "BGP MultiNexthop Attribute", Kaliraj Vairavakkalai, Jeyananth Jeganathan, Mohan Nanduri, Avinash Lingala, 2025-03-25, Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update message. This nexthop can be encoded in either the top- level BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). Forwarding information related to the nexthop is scattered across various attributes, extended communities or the NLRI field. This document defines a new optional non-transitive BGP attribute called "MultiNexthop (MNH)" with IANA code TBD. The MNH provides two things: it allows carrying the Nexthop and related forwarding information in one BGP attribute. The MNH also enables carrying an ordered set of multiple Nexthops in the same attribute, with forwarding information scoped on a per Nexthop basis. "Advertising SID Algorithm Information in BGP", Yao Liu, Shaofu Peng, Gyan Mishra, 2025-04-10, This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. "SR Policies Extensions for Network Resource Partition in BGP-LS", Ran Chen, Jie Dong, Detao Zhao, Liyan Gong, Yongqing Zhu, Ran Pang, 2025-01-26, 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 ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). "BGP Flow Specification Version 2 - for Basic IP", Susan Hares, Donald Eastlake, Jie Dong, Chaitanya Yadlapalli, Sven Maduschke, 2025-03-03, BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. "Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members", Changwang Lin, Zhenqiang Li, Ran Pang, Ketan Talaulikar, Mengxiao Chen, 2025-03-02, There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. "Link-Local Next Hop Capability for BGP", Russ White, Jeff Tantsura, Donatas Abraitis, 2025-05-30, BGP [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. To support IPv6 reachability, BGP relies heavily on its Multiprotocol Extensions as defined in [RFC2545], which is crucial for enabling BGP-4 to advertise IPv6 routes alongside IPv4. This extension not only permits the exchange of IPv6 routing information but also establishes the structure for IPv6 next hop handling within BGP updates. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. [RFC2545] introduced the ability to advertise a global IPv6 address as the BGP next hop. When the advertising system is directly attached, it may include both a global and an IPv6 link-local address or only a global address, when next hop length is set to 16 bytes. This document updates the specification to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 link-local address is available. This clarification applies specifically to IPv6 link-local addresses and does not pertain to IPv4 link-local addresses as defined in [RFC3927]. "YANG Data Model for BGP about RPKI", Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Di Ma, 2025-05-06, This document defines YANG data models for configuring and managing BGP information about Resource Public Key Infrastructure (RPKI). Internet Area Working Group (intarea) ------------------------------------- "IP Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley, 2025-05-09, This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels. "Communicating Proxy Configurations in Provisioning Domains", Tommy Pauly, Dragana Damjanovic, Yaroslav Rosomakho, 2025-03-03, This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and a list of DNS zones that are accessible via 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. "Adding Extensions to ICMP Errors for Originating Node Identification", Bill Fenner, Reji Thomas, 2025-03-26, RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all nexthops are IPv6 nexthops, even for IPv4 routes). "PROBE: A Utility for Probing Interfaces", Bill Fenner, Ron Bonica, Reji Thomas, Jen Linkova, Chris Lenart, Mohamed Boucadair, 2025-01-24, This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. "ICMP Extension Header Length Field", Ron Bonica, Xiaoming He, Xiao Min, Tal Mizrahi, 2025-03-15, The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. "IPv4 routes with an IPv6 next hop", Juliusz Chroboczek, Warren Kumari, Toke Hoeiland-Joergensen, 2025-05-27, This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. IOT Operations (iotops) ----------------------- "Comparison of CoAP Security Protocols", John Mattsson, Francesca Palombini, Malisa Vucinic, 2025-06-04, This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. "Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez, 2025-01-08, The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. "Authorized update to MUD URLs", Michael Richardson, Wei Pan, Eliot Lear, 2025-05-08, This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls "Ownership and licensing statements in YANG", Eliot Lear, Carsten Bormann, 2025-05-08, This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. "MUD-Based RATS Resources Discovery", Henk Birkholz, Michael Richardson, Peter Liu, 2025-05-27, Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. IP Performance Measurement (ippm) --------------------------------- "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2025-02-24, Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. "Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields", Frank Brockners, Shwetha Bhandari, Tal Mizrahi, Justin Iurman, 2025-02-28, 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. "Test Protocol for One-way IP Capacity Measurement", Len Ciavattone, Ruediger Geib, 2025-06-12, This document addresses the problem of protocol support for measuring Network Capacity metrics specified by RFC 9097. The Method of Measurement discussed there requires a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This document defines the UDP Speed Test Protocol for conducting RFC 9097 and other related measurements. "IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option", Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, 2025-04-06, 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. "Hybrid Two-Step Performance Measurement Method", Greg Mirsky, Wang Lingqiang, Guo Zhui, Haoyu Song, Pascal Thubert, 2025-02-25, The development and advancements in network operation automation have brought new measurement methodology requirements. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. That task can be solved using on-path telemetry, also called hybrid measurement. An on-path telemetry method allows the collection of essential information that reflects the operational state and network performance experienced by the packet. This document introduces a method complementary to on-path telemetry that causes the generation of telemetry information. This method, referred to as Hybrid Two-Step (HTS), separates the act of measuring and/or calculating the performance metric from collecting and transporting network state. The HTS packet traverses the same set of nodes and links as the trigger packet, thus simplifying the correlation of informational elements originating on nodes traversed by the trigger packet. "Alternate Marking Deployment Framework", Giuseppe Fioccola, Keyi Zhu, Thomas Graf, Massimo Nilo, Lin Zhang, 2025-02-27, This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. "Quality of Outcome", Bjorn Teigen, Magnus Olden, 2025-06-02, This document introduces the Quality of Outcome (QoO) framework, a novel approach to network quality assessment designed to align with the needs of application developers, users, and operators. By leveraging the Quality Attenuation metric, QoO provides a unified method for defining and evaluating application-specific network requirements while ensuring actionable insights for network optimization and simple quality scores for end-users. "Performance Measurement with Asymmetrical Traffic Using STAMP", Greg Mirsky, Ernesto Ruffini, Henrik Nydell, Richard Foote, Will Hawkins, 2025-05-05, This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables control of the length and/or number of reflected packets during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", Rakesh Gandhi, Tianran Zhou, Zhenqiang Li, 2025-06-02, 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. "A YANG Data Model for the Alternate Marking Method", Thomas Graf, Minxue Wang, Giuseppe Fioccola, Tianran Zhou, Xiao Min, 2025-01-08, Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. "On-Path Telemetry YANG Data Model", Giuseppe Fioccola, Tianran Zhou, 2025-05-19, This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Group Key Management using IKEv2", Valery Smyslov, Brian Weis, 2025-03-16, This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. "Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2)", Sandeep Kampati, Wei Pan, Paul Wouters, Bharath Meduri, Meiling Chen, Valery Smyslov, 2025-03-03, This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. "ESP Header Compression with Diet-ESP", Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi, 2025-04-07, This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression is expressed through the Static Context Header Compression architecture. "Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)", Daniel Migault, Maryam Hatami, Daiying Liu, Stere Preda, J. Atwood, Sandra Cespedes, Tobias Guggemos, David Schinazi, 2025-03-16, This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. "Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security", Valery Smyslov, 2025-05-23, An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC8784, but also protects the initial IKEv2 SA. RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations. "Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2025-03-16, This document clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this transform type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC", Tirumaleswar Reddy.K, Valery Smyslov, Scott Fluhrer, 2025-04-11, 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. "IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP", Antony Antony, Steffen Klassert, 2025-03-18, This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. "Encrypted ESP Echo Protocol", Antony Antony, Steffen Klassert, 2025-04-03, 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. "ESP Echo Protocol", Lorenzo Colitti, Jen Linkova, Michael Richardson, 2025-04-30, This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. "Enhanced Encapsulating Security Payload (EESP)", Steffen Klassert, Antony Antony, Christian Hopps, 2025-04-30, 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), 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 (e.g., for CPU pinning and QoS support), and a crypt-offset to allow for exposing inner flow information for middlebox use. "Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)", Panos Kampanakis, Gerardo Ravago, 2025-05-01, NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. "IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP)", Steffen Klassert, Antony Antony, Tobias Brunner, Valery Smyslov, 2025-05-13, This document specfies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in draft-klassert-ipsecme-eesp, provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. Network Inventory YANG (ivy) ---------------------------- "A Base YANG Data Model for Network Inventory", Chaode Yu, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Phil Bedard, 2025-05-21, This document defines a base YANG data model for 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. "A Network Data Model for Inventory Topology Mapping", Bo Wu, Mohamed Boucadair, Cheng Zhou, Qin WU, 2025-04-09, This document defines a YANG model to map the network inventory data with the topology model to form a base underlay network. The model facilitates the correlation between the layer (e.g., Layer 2 and 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 Data Model for Network Inventory Location", Bo Wu, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Phil Bedard, 2025-04-17, This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. "A YANG Network Data Model of Network Inventory Software Extensions", Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair, 2025-06-10, The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for non-physical NEs (e.g., controllers, virtual routers, virtual firewalls) and software components (e.g., platform operating system (OS), software-patch). JSON Mail Access Protocol (jmap) -------------------------------- "JSON Meta Application Protocol (JMAP) for Calendars", Neil Jenkins, Michael Douglass, 2024-11-13, 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. "JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications", Neil Jenkins, 2025-05-05, This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further request. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Proof Token and CBOR Proof Token", Michael Jones, David Waite, Jeremie Miller, 2025-04-08, 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 of JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. "JSON Web Proof", David Waite, Michael Jones, Jeremie Miller, 2025-04-08, 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 protected header to prevent replay. "JSON Proof Algorithms", Michael Jones, David Waite, Jeremie Miller, 2025-04-08, 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. "Fully-Specified Algorithms for JOSE and COSE", Michael Jones, Orie Steele, 2025-05-11, This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFC 7518, RFC 8037, and RFC 9053. It deprecates polymorphic algorithms defined by RFC 8037 and RFC 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFC 7518 and RFC 9053. "Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)", Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones, 2025-06-12, 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. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. This document defines the use of the HPKE with JOSE. "Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE", Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig, 2025-05-06, 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/. "JOSE: Deprecate 'none' and 'RSA1_5'", Neil Madden, 2025-04-02, This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations should meet. Key Transparency (keytrans) --------------------------- "Key Transparency Architecture", Brendan McMillion, 2025-02-25, This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) 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 KT to a number of common applications. "Key Transparency Protocol", Brendan McMillion, Felix Linker, 2025-06-04, 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. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "The Hashed Token SASL Mechanism", Florian Schmaus, Christoph Egger, 2025-02-21, This document specifies the family of Hashed Token SASL mechanisms which enable a proof-of-possession-based authentication scheme and are meant to be used to quickly re-authenticate of a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round- trip property. The SASL mechanism specified herein further provides hash agility, mutual authentication and support for channel binding. "SASL Remember Me", Ben Bucksch, Stephen Farrell, 2025-02-28, Introduces a SASL mechanism that allows the application to stay logged in and re-login without user interaction, after completing a time-consuming SASL login mechanism that involves the user. Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)", Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson, 2025-03-03, 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. "Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)", Marco Tiloca, 2025-03-03, This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). "Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)", Marco Tiloca, Rikard Hoeglund, 2025-03-03, 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 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. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, this document defines a set of well-known EDHOC application profiles. "EDHOC Authenticated with Pre-Shred Keys (PSK)", Elsa, Goeran Selander, John Mattsson, Rafael Marin-Lopez, 2025-03-01, 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. "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility", Christian Amsuess, 2025-01-27, This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. "Remote attestation over EDHOC", Yuxuan Song, Goeran Selander, 2025-03-03, 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. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Header Protection for Cryptographically Protected E-mail", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2025-01-06, S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections. "Guidance on End-to-End E-mail Security", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2025-01-08, End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers to help mitigate those risks, and to make end-to-end e-mail simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems. "Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray, 2025-01-30, This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and use EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. The updates maintain backward compatibility with CMP version 2 wherever possible. Updates to CMP version 2 are improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. CMP version 3 is introduced for changes to the ASN.1 syntax, which are support of EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann messages. This document obsoletes RFC 4210 and together with I-D.ietf-lamps- rfc6712bis and it also obsoletes RFC 9480. Appendix F of this document updates the Section 9 of RFC 5912. "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray, 2025-01-09, This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates to RFC 6712 specified in RFC 9480 Section 3. These updates introduce CMP URIs using a Well-known prefix. It obsoletes RFC 6712 and together with I-D.ietf-lamps-rfc4210bis and it also obsoletes RFC 9480. "Clarification and enhancement of RFC7030 CSR Attributes definition", Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins, 2025-05-08, This document updates RFC7030, Enrollment over Secure Transport (EST), clarifying how the Certificate Signiing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object IDs (OID) and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. RFC7030 (EST) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. As a result, there was not universal understanding of what was specified. This document clarifies the encoding rules. This document therefore also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subject Distinguished Name (DN). "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)", Sean Turner, Panos Kampanakis, Jake Massimo, Bas Westerbaan, 2025-04-16, The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also described. "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", Jake Massimo, Panos Kampanakis, Sean Turner, Bas Westerbaan, 2025-05-22, Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas Westerbaan, 2025-01-13, SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. "Use of ML-KEM in the Cryptographic Message Syntax (CMS)", Julien Prat, Mike Ounsworth, Daniel Van Geest, 2025-04-22, Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameters sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML- KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. "Composite ML-KEM for use in X.509 Public Key Infrastructure", Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer, 2025-06-16, 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. "Use of Remote Attestation with Certification Signing Requests", Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith, 2025-05-25, 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 Evidence 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 Evidence to a Certification Authority. Including Evidence 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. "Updates to Lightweight OCSP Profile for High Volume Environments", Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner, 2024-09-13, This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1. "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA", Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis, 2025-05-30, Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also described. "Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure", Daniel Van Geest, Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Stavros Kousidis, 2024-12-12, This document specifies algorithm identifiers and ASN.1 encoding formats for the stateful hash-based signature (HBS) schemes Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when those digital signatures are used in Internet X.509 certificates and certificate revocation lists. "Composite ML-DSA for use in X.509 Public Key Infrastructure", Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer, 2025-06-16, 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 security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application 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. "Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax", Alicja Kario, 2025-04-25, This document specifies additions and amendments to RFCs 7292 and 8018. It also obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. "Certificate Management over CMS (CMC)", Joe Mandel, Sean Turner, 2025-05-28, 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", Joe Mandel, Sean Turner, 2025-05-28, 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", Joe Mandel, Sean Turner, 2025-05-28, 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. "Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Ben S, Adam R, Daniel Van Geest, 2025-06-08, The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. "X.509 Extended Key Usage (EKU) for configuration, updates and safety-communication", Hendrik Brockhaus, David Goltzsche, 2025-04-09, RFC 5280 defines the Extended Key Usage (EKU) extension and several extended key purposes (KeyPurposeIds) for use with that extension in X.509 certificates. This document defines KeyPurposeIds for general- purpose and trust anchor configuration files, for software and firmware update packages, and for safety-critical communication to be included in the EKU extension of X.509 v3 public key certificates. "An Attribute for Statement of Possession of a Private Key", Russ Housley, 2025-06-15, This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. "Unsigned X.509 Certificates", David Benjamin, 2025-06-11, This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. "A Mechanism for X.509 Certificate Discovery", Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel, 2025-04-09, This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. "CAA Security Tag for Cryptographically-Constrained Domain Validation", Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal, 2025-05-03, Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which may be located between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man-in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically- constrained domain validation procedures. "Clarification to processing Key Usage values during CRL validation", Corey Bonnell, Tadahiko Ito, Tomofumi Okubo, 2025-05-20, 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. "PKCS #8 Private-Key Information Content Types", Joe Mandel, Russ Housley, Sean Turner, 2025-05-22, This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP Traffic Engineering", Dino Farinacci, Michael Kowal, Parantap Lahiri, Padma Pillay-Esnault, 2025-05-13, This document describes how 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 locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. "LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci, 2025-05-08, 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. "LISP Control-Plane ECDSA Authentication and Authorization", Dino Farinacci, Erik Nordmark, 2025-02-09, This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. "Geo-Intelligence Network Based On H3 and LISP", Sharon Barkai, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Jordi Paillisse, Dino Farinacci, 2025-03-30, Lisp-Nexagon is a geospatial intelligence network protocol designed to support physical-world applications such as transportation, public safety, and logistics. It combines the Locator/ID Separation Protocol (LISP) with the H3 spatial indexing system to enable distributed agents to report, aggregate, and disseminate geospatial state information. "LISP Map Server Reliable Transport", Balaji Venkatachalapathy, Marc Portoles-Comeras, Darrel Lewis, Isidor Kouvelas, Chris Cassar, 2025-05-08, 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 use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. "LISP Geo-Coordinates", Dino Farinacci, 2025-06-05, This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo- Coordinate. This document updates RFC8060. "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay Hooda, 2025-03-28, This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination). "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", Victor Moreno, Dino Farinacci, 2025-02-25, This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. "The Locator/ID Separation Protocol (LISP) for Multicast Environments", Dino Farinacci, David Meyer, John Zwiebel, Stig Venaas, Vengada Govindan, 2025-01-29, This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. "LISP Multicast Overlay Group to Underlay RLOC Mappings", Vengada Govindan, Dino Farinacci, Aswin Kuppusami, Stig Venaas, 2025-05-12, This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. "LISP Canonical Address Format (LCAF)", Alvaro Retana, Dino Farinacci, David Meyer, Job Snijders, 2025-06-12, This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. Link State Routing (lsr) ------------------------ "A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane", Yingzhen Qu, Acee Lindem, Zhaohui Zhang, Helen Chen, 2025-05-09, This document defines a YANG data model that can be used to manage OSPF Extensions for Segment Routing over the MPLS data plane. "A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane", Stephane Litkowski, Yingzhen Qu, Acee Lindem, Helen Chen, Jeff Tantsura, 2025-05-06, This document defines a YANG data model that can be used to manage IS-IS Extensions for Segment Routing over the MPLS data plane. "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, 2025-03-01, This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee Lindem, Peter Psenak, Yingzhen Qu, 2025-02-19, It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. "IS-IS YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, Stephane Litkowski, 2025-02-27, 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, IS-IS Application-Specific Link Attributes as defined in RFC 9479, IS-IS Flexible Algorithm as defined in RFC 9350, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)", Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li, 2025-04-13, 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. "OSPF-GT (Generalized Transport)", Acee Lindem, Yingzhen Qu, Abhay Roy, Sina Mirtorabi, 2025-06-02, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. "IGP Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints", Shraddha Hegde, William Britto, Rajesh Shetty, Bruno Decraene, Peter Psenak, Tony Li, 2025-02-13, Many networks configure the IGP link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms [RFC9350]provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. "YANG Data Model for OSPF SRv6", Yingzhen Qu, Zhibo Hu, Xuesong Geng, Syed Raza, Acee Lindem, 2025-03-02, This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. "YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng, Qiufang Ma, 2025-03-02, This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. "IS-IS Distributed Flooding Reduction", Russ White, Shraddha Hegde, Tony Przygienda, Luay Jalil, Dan Voyer, 2025-04-25, 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. "IGP Flexible Algorithms Reverse Affinity Constraint", Peter Psenak, Jakub Horn, Dhamija, 2025-04-22, An IGP Flexible Algorithm (Flex-Algorithm) enables the computation of constraint-based paths within an IGP domain, allowing operators to influence path selection according to administrative policies. This document defines an extension to Flex-Algorithm that allows the inclusion or exclusion of links from path computation based on Administrative Groups (also known as link affinities) associated with the reverse direction of the path under computation. This extension enhances the path selection capabilities of Flex- Algorithm by enabling reverse-affinity-based constraints, which are particularly useful for scenarios where path symmetry or directional link attributes are operationally significant. "IGP Unreachable Prefix Announcement", Peter Psenak, Clarence Filsfils, Dan Voyer, Shraddha Hegde, Gyan Mishra, 2025-06-05, Summarization is often used in multi-area or 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 document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. "Multi-Part TLVs in IS-IS", Parag Kaneriya, Tony Li, Tony Przygienda, Shraddha Hegde, Les Ginsberg, 2025-04-25, New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. "Advertising Unreachable Links in OSPF", Liyan Gong, Weiqiang Cheng, Changwang Lin, Acee Lindem, Ran Chen, 2025-06-06, In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe). "Updates to Anycast Property advertisement for OSPFv2", Ran Chen, Detao Zhao, Peter Psenak, Ketan Talaulikar, Changwang Lin, 2025-06-02, Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. "YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS)", Yingzhen Qu, Les Ginsberg, Tony Przygienda, Bruno Decraene, Yongqing Zhu, 2025-05-05, 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", Yingzhen Qu, Les Ginsberg, Tony Przygienda, Bruno Decraene, Yongqing Zhu, 2025-05-05, 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", Yingzhen Qu, Les Ginsberg, Tony Przygienda, Bruno Decraene, Yongqing Zhu, 2025-05-05, The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. "Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members", Liyan Gong, Changwang Lin, Mengxiao Chen, Ketan Talaulikar, Les Ginsberg, Peter Psenak, 2025-03-17, In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) [IEEE802.1AX]) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE, it is essential to know the connectivity relationships among bundle members. This document describes how OSPF and IS-IS would advertise the remote interface identifiers for Layer 2 bundle members. The corresponding extension of BGP-LS is also specified. "IGP Reverse SPF Algorithm", Peter Psenak, Jakub Horn, Les Ginsberg, 2025-03-19, IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. Link State Vector Routing (lsvr) -------------------------------- "BGP Link-State Shortest Path First (SPF) Routing", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2025-01-23, Many Massively Scaled Data Centers (MSDCs) have converged on simplified L3 (Layer 3) routing. Furthermore, requirements for operational simplicity has led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. "Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers", Keyur Patel, Acee Lindem, Shawn Zandi, Gaurav Dawra, Jie Dong, 2025-01-23, This document discusses the usage and applicability of BGP Link-State Shortest Path First (BGP-SPF) extensions in data center networks utilizing Clos or Fat-Tree topologies. The document is intended to provide simplified guidance for the deployment of BGP-SPF extensions. "Layer-3 Discovery and Liveness", Randy Bush, Rob Austein, Russ Housley, Keyur Patel, 2025-04-30, In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. MAC Address Device Identification for Network and Application Services (madinas) -------------------------------------------------------------------------------- "Randomized and Changing MAC Address: Context, Network Impacts, and Use Cases", Jerome Henry, Yiu Lee, 2024-12-20, To limit the privacy issues created by the association between a device, its traffic, its location, and its user in [IEEE_802] networks, client and client Operating System vendors have started implementing MAC address randomization. This technology is particularly important in Wi-Fi [IEEE_802.11] networks due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC address randomization purposes. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines two existing frameworks to maintain user privacy while preserving user quality of experience and network operation efficiency. Mail Maintenance (mailmaint) ---------------------------- "SMTP Service Extension for Client Identity", William Storey, Deion Yu, Shaun Johnson, 2025-05-30, Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as SMTP authentication have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of authenticated SMTP activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the SMTP service protocol called "CLIENTID" that a SMTP client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identify verification method in a similar manner to other Multi-Factor authentication techniques. "IMAP Service Extension for Client Identity", Deion Yu, Shaun Johnson, 2025-05-30, Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as [IMAP] have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of [IMAP] activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the [IMAP] service protocol called "CLIENTID" that an [IMAP] client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identity verification method in a similar manner to other Multi-Factor authentication techniques. "Adding a Wrong Recipient URL for Handling Misdirected Emails", David Weekly, John Levine, 2025-02-22, This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. "Mail Autoconfig", Ben Bucksch, 2025-03-21, Set up a mail account with only email address and password. "Registration of further IMAP/JMAP keywords and mailbox attribute names", Neil Jenkins, Daniel Eggert, 2025-06-07, This document defines a number of keywords that have been in use by Fastmail and Apple for some time. It defines their intended use. Additionally some mailbox names with special meaning have been in use by Fastmail, and this document defines their intended use. This document registers all of these names with IANA to avoid name collisions. "IMAP UIDBATCHES Extension", Daniel Eggert, 2025-04-23, The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve UIDs from the server such that these UIDs split the messages of a mailbox into equally sized batches. It enables the client to perform operations such as FETCH/SEARCH/STORE on these specific batches. This limits the number of messages that each command operates on, enabling better control over resource usage and response sizes. "OAuth Profile for Open Public Clients", Neil Jenkins, Ben Bucksch, 2025-03-18, This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. "Interoperable Email Addresses for SMTPUTF8", Arnt Gulbrandsen, Jiankang Yao, 2025-01-15, 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", Arnt Gulbrandsen, Jiankang Yao, 2025-01-15, 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. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP DiffServ Aware Credit Window Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, Donald Eastlake, 2025-03-03, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. "Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng, David Wiggins, Stan Ratliff, Lou Berger, Eric Kinzie, 2025-03-25, This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are extensible and reusable. "Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item", Bow-Nan Cheng, David Wiggins, Lou Berger, Don Fedyk, 2025-03-27, This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/ packet content such as destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items, and Sub-Data Items are defined to support DiffServ and Ethernet traffic classification. "DLEP IEEE 802.1Q Aware Credit Window Extension", David Wiggins, Lou Berger, Donald Eastlake, 2025-03-24, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. "DLEP Radio Quality Extension", Henning Rogge, 2025-05-18, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. "DLEP Radio Band Extension", Henning Rogge, 2025-05-12, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the frequency bands used by the radio. "DLEP Radio Channel Utilization Extension", Henning Rogge, 2025-05-12, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- "QUIC-Aware Proxying Using HTTP", Tommy Pauly, Eric Rosenberg, David Schinazi, 2025-03-03, 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. "Proxying Bound UDP in HTTP", David Schinazi, Abhijit Singh, 2025-06-16, 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. "Proxying Ethernet in HTTP", Alejandro Sedeno, 2025-01-27, 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 Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. "DNS Configuration for Proxying IP in HTTP", David Schinazi, Yaroslav Rosomakho, 2025-03-03, Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. MBONE Deployment (mboned) ------------------------- "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2025-05-07, This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast streams. It provides a management view for network administrators to obtain information about multicast services. "Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, Max Franke, 2025-05-07, 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", Jake Holland, Kyle Rose, Max Franke, 2025-05-08, 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", Jake Holland, Kyle Rose, Max Franke, 2025-05-08, 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. "Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang, Yisong Liu, Ying Cheng, Gyan Mishra, 2025-01-20, This document discusses multicast redundant ingress router failover issues, including global multicast and service provider network MVPN use cases. This document analyzes the specifications for global multicast and multicast VPN fast upstream failover and ingress PE standby modes and the benefits of each mode. "YANG Data Model for Automatic Multicast Tunneling", Yisong Liu, Changwang Lin, Zheng Zhang, Xuesong Geng, Vinod Nagaraj, 2025-02-15, This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. "Non-source-routed Multicast in SR Networks", Zhaohui Zhang, IJsbrand Wijnands, Hooman Bidgoli, Yisong Liu, 2025-04-23, 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. Media Type Maintenance (mediaman) --------------------------------- "Media Type Specifications and Registration Procedures", Mark Nottingham, Pete Resnick, 2025-05-22, This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. More Instant Messaging Interoperability (mimi) ---------------------------------------------- "More Instant Messaging Interoperability (MIMI) message content", Rohan Mahy, 2025-02-28, This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. "More Instant Messaging Interoperability (MIMI) using HTTPS and MLS", Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert, 2025-03-03, 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", Rohan Mahy, 2025-03-02, 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. Machine Learning for Audio Coding (mlcodec) ------------------------------------------- "Extension Formatting for the Opus Codec", Timothy Terriberry, Jean-Marc Valin, 2025-01-21, This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. "Deep Audio Redundancy (DRED) Extension for the Opus Codec", Jean-Marc Valin, Jan Buethe, 2025-04-29, This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. "Integration of Speech Codec Enhancement Methods into the Opus Codec", Jan Buethe, Jean-Marc Valin, 2025-06-08, This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Extensions", Raphael Robert, 2025-02-19, The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. "Flexible Hybrid PQ MLS Combiner", Joel, Britta Hale, Marta Mularczyk, Xisen Tian, 2025-02-26, This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ security 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. MODeration PrOceDures (modpod) ------------------------------ "IETF Community Moderation", Lars Eggert, Eliot Lear, 2025-06-03, The IETF will treat people with kindness and grace, but not endless patience. This document describes the creation of a moderator team for all the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration. Media OPerationS (mops) ----------------------- "Network Overlay Impacts to Streaming Video", Glenn Deen, Sanjay Mishra, 2025-03-02, This document examines the operational impacts to streaming video applications caused by changes to network policies by network overlays. The network policy changes include IP address assignment, transport protocols, routing, DNS resolver which in turn affect a variety of important content delivery aspects such as latency, CDN cache selection, delivery path choices, traffic classification and content access controls. Media Over QUIC (moq) --------------------- "Media over QUIC Transport", Suhas Nandakumar, Victor Vasiliev, Ian Swett, Alan Frindell, 2025-04-28, 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. "WARP Streaming Format", Will Law, Luke Curley, Victor Vasiliev, Suhas Nandakumar, Kirill Pugin, 2025-03-16, This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. "Low Overhead Media Container", Mo Zanaty, Suhas Nandakumar, Peter Thatcher, 2025-03-31, This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It further defines the LOC Streaming Format for the MOQ Common Catalog format for publishers to annouce and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. Multiprotocol Label Switching (mpls) ------------------------------------ "Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data", Tarek Saad, Kiran Makhijani, Haoyu Song, Greg Mirsky, 2024-09-23, This document presents use cases that have a common feature that may be addressed by encoding network action indicators and associated ancillary data within MPLS packets. There is community interest in extending the MPLS data plane to carry such indicators and ancillary data to address the use cases that are described in this document. The use cases described in this document are not an exhaustive set, but rather the ones that are actively discussed by members of the IETF MPLS, PALS, and DetNet working groups from the beginning of work on the MPLS Network Action until the publication of this document. "MPLS Network Actions (MNA) Framework", Loa Andersson, Stewart Bryant, Matthew Bocci, Tony Li, 2024-12-27, This document describes an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions. The document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. "MPLS Network Action (MNA) Sub-Stack Solution", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella, 2025-03-03, This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the 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. This solution document specifies In-stack network action and In-stack data specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". "IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack", Kireeti Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson, Jie Dong, 2024-12-05, This document creates a new IANA registry (called the Post-stack First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document sets out some documentation requirements for registering new values, and requirements that make processing MPLS packets easier and more robust. The relationship between the IANA IP Version Numbers (RFC 2780) and the Post-stack First Nibble registry is described in this document. This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. "Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane", Xiao Min, Shaofu Peng, Liyan Gong, Rakesh Gandhi, Carlos Pignataro, 2025-06-06, Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions, called segments. SR can be instantiated over the MPLS data plane. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to- end paths in Segment Routing networks. This document defines procedures (i.e. six new Target forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include Path Segment Identifiers. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS OAM capabilities. "Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks", Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min, 2025-06-05, Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without adding an IP/UDP header for PWs and LSPs. "Supporting In Situ Operations, Administration and Maintenance Using MPLS Network Actions", Rakesh Gandhi, Greg Mirsky, Tony Li, Haoyu Song, Bin Wen, 2025-05-30, In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and record the operational state and telemetry information using, for example, Pre- allocated, Proof-of-Transit, Edge-To-Edge or Incremental IOAM Option, that can be used to calculate various performance metrics. RFC 9326 defined the IOAM Direct Export (IOAM-DEX) Option in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy on each node along the path. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transfer data needed for these actions. This document explores the MNA mechanisms to collect and transport the on-path operational state, and telemetry information IOAM data fields, including IOAM-DEX Option. "Post-Stack MPLS Network Action (MNA) Solution", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong, 2025-02-16, 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 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 (PSD) specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "MPLS Network Actions (MNA) Framework". "MPLS Network Actions for Network Resource Partition Selector", Tony Li, John Drake, Vishnu Beeram, Tarek Saad, Israel Meilik, 2025-05-13, An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provided the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. "Post-Stack MPLS Network Action (MNA) Solution", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong, 2025-05-30, 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 "Requirements for MPLS Network Actions." This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "MPLS Network Actions (MNA) Framework." Network Configuration (netconf) ------------------------------- "A YANG Data Model for RESTCONF Clients and Servers", Kent Watsen, 2025-04-24, This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. These modules support both standard and call home RESTCONF connections. For initiating connections, both modules configure HTTPS. For listening for connections, both modules configure HTTPS and HTTP. Whilst RESTCONF supports only HTTPS, HTTP may be configured for when a TLS-terminator is deployed in front of the listener. "A YANG Data Model for NETCONF Clients and Servers", Kent Watsen, 2025-04-24, This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. "An HTTPS-based Transport for YANG Notifications", Mahesh Jethanandani, Kent Watsen, 2024-02-01, This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. "YANG Groupings for HTTP Clients and HTTP Servers", Kent Watsen, 2025-06-06, This document primarily presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). This document additionally presents a third YANG module, to define a grouping for URIs. "Subscription to Notifications in a Distributed Architecture", Tianran Zhou, Guangying Zheng, Eric Voit, Thomas Graf, Pierre Francois, 2025-06-08, 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. "UDP-based Transport for Configured Subscriptions", Alex Feng, Pierre Francois, Tianran Zhou, Thomas Graf, Paolo Lucente, 2025-05-14, 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 enable 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. "Adaptive Subscription to YANG Notification", Qin WU, Peng Liu, Qiufang Ma, Wei Wang, Zhixiong Niu, 2025-05-21, 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. "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li, 2025-04-03, 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", Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li, 2025-04-03, This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li, 2025-04-03, 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. "Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", Sean Turner, Russ Housley, 2024-01-18, RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data. "Transaction ID Mechanism for NETCONF", Jan Lindblad, 2025-02-20, NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store 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. "Support of Versioning in YANG Notifications Subscription", Thomas Graf, Benoit Claise, Alex Feng, 2025-04-05, This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG-Push subscription state change notification is proposed. "NETCONF Private Candidates", James Cumming, Robert Wills, 2025-01-21, This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. "External Trace ID for Configuration Tracing", Jean Quilbeuf, Benoit Claise, Thomas Graf, Diego Lopez, Sun Qiong, 2025-03-18, Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. "YANG Groupings for UDP Clients and UDP Servers", Alex Feng, Pierre Francois, Kent Watsen, 2025-05-14, This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. "NETCONF Extension to support Trace Context propagation", Roque Gagliano, Kristian Larsson, Jan Lindblad, 2025-03-03, 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", Roque Gagliano, Kristian Larsson, Jan Lindblad, 2025-03-03, This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. "NETCONF over QUIC", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson, 2025-05-22, This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS. 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 "Augmented-by Addition into the IETF-YANG-Library", Zhuoyao Lin, Benoit Claise, Ignacio Martinez-Casanueva, 2025-05-28, This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. "YANG Groupings for QUIC clients and QUIC servers", Per Andersson, 2025-02-24, This document defines three 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. 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 "NETCONF Transport Port Numbers", Mohamed Boucadair, 2025-05-10, This document releases NETCONF-related port number IANA assignments that were made for inappropriate transport protocols or for Historic NETCONF-related protocols. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Configuration Working Group mailing list (netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/netconf-port-numbers. "Extensible YANG Model for YANG-Push Notifications", Alex Feng, Pierre Francois, Thomas Graf, Benoit Claise, 2025-03-17, 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 Notification Transport Capabilities", Qin WU, Qiufang Ma, Alex Feng, Thomas Graf, 2025-06-16, This document specifies a YANG module for YANG notifications transport capabilities which augments the notification capabilities model. The module provides transport protocol, transport encoding, and transport encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. Network Modeling (netmod) ------------------------- "Common Interface Extension YANG Data Models", Robert Wilton, Scott Mansfield, 2025-03-20, 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. "Sub-interface VLAN YANG Data Models", Robert Wilton, Scott Mansfield, 2025-04-09, 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. "YANG Module Versioning Requirements", Joe Clarke, 2025-01-12, This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. "Common YANG Data Types", Juergen Schoenwaelder, 2024-10-21, This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. "Updated YANG Module Revision Handling", Robert Wilton, Reshad Rahman, Balazs Lengyel, Joe Clarke, Jason Sterne, 2025-02-06, 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. "YANG Packages", Robert Wilton, Reshad Rahman, Joe Clarke, Jason Sterne, Bo Wu, 2025-03-03, This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. It describes how packages: are represented on a server, can be defined in offline YANG instance data files, and can be used to define the content schema associated with YANG instance data files. "YANG Semantic Versioning", Joe Clarke, Robert Wilton, Reshad Rahman, Balazs Lengyel, Jason Sterne, Benoit Claise, 2025-02-07, This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 8407, and 8525. "System-defined Configuration", Qiufang Ma, Qin WU, Chong Feng, 2025-02-12, The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This document introduces the concept of system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients. This document updates RFC 8342. "Extensions to the Access Control Lists (ACLs) YANG Model", Oscar de Dios, Samier Barguil, Mohamed Boucadair, Qin WU, 2025-04-03, RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", Andy Bierman, Mohamed Boucadair, Qin WU, 2025-06-05, This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. "YANG Metadata Annotation for Immutable Flag", Qiufang Ma, Qin WU, Balazs Lengyel, Hongwei Li, 2025-05-15, This document defines a way to formally document an existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not proscriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. "A Common YANG Data Model for Scheduling", Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King, 2025-06-12, This document defines common types and groupings that are meant to be used for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling status. "YANG module file name convention", Per Andersson, 2025-02-25, 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. "An Update to YANG Module Names Registration", Andy Bierman, Mohamed Boucadair, Qin WU, 2025-05-26, This document amends the IANA guidance on the uniqueness of YANG module and submodule names. The document updates RFC 6020 to clarify how modules and their revisions are handled by IANA. Network File System Version 4 (nfsv4) ------------------------------------- "Internationalization for the NFSv4 Protocols", David Noveck, 2025-05-16, This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, 2025-05-23, 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 as 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. Network Management Operations (nmop) ------------------------------------ "A YANG Data Model for Network Incident Management", Tong Hu, Luis Contreras, Qin WU, Nigel Davis, Chong Feng, 2025-06-14, 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 amount 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. "An Architecture for YANG-Push to Message Broker Integration", Thomas Graf, Ahmed Elhassany, 2025-03-03, 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. "Some Key Terms for Network Fault and Problem Management", Nigel Davis, Adrian Farrel, Thomas Graf, Qin WU, Chaode Yu, 2025-05-18, This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG models and management protocols that report, make visible, or manage network faults and problems. "A Framework for a Network Anomaly Detection Architecture", Thomas Graf, Wanting Du, Pierre Francois, Alex Feng, 2025-05-08, This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. "SIMAP: Concept, Requirements, and Use Cases", Olga Havel, Benoit Claise, Oscar de Dios, Thomas Graf, 2025-03-03, 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. "Semantic Metadata Annotation for Network Anomaly Detection", Thomas Graf, Wanting Du, Alex Feng, Vincenzo Riccobene, 2025-05-08, This document explains the motivation for defining semantic metadata annotations to help testing, validating and comparing Outlier and Symptom detection systems. These semantic annotations can be supported by supervised and semi-supervised machine learning algorithms and enable data exchange among network operators, vendors and academia, making anomalies apprehensible for humans. The proposed semantics uniforms the network anomaly data exchange between operators and vendors to improve their Service Disruption Detection Systems. "An Experiment: Network Anomaly Lifecycle", Vincenzo Riccobene, Thomas Graf, Wanting Du, Alex Feng, 2025-05-08, Network Anomaly Detection is the act of detecting problems in the network. Accurately detect problems is very challenging for network operators in production networks. Good results require a lot of expertise and knowledge around both the implied network technologies and the connectivity services provided to customers, apart from a proper monitoring infrastructure. In order to facilitate network anomaly detection, novel techniques are being introduced, including programmatical, rule-based and AI-based, with the promise of improving scalability and the hope to keep a high detection accuracy. To guarantee acceptable results, the process needs to be properly designed, adopting well-defined stages to accurately collect evidence of anomalies, validate their relevancy and improve the detection systems over time, iteratively. This document describes a well-defined approach on managing the lifecycle process of a network anomaly detection system, spanning across the recording of its output and its iterative refinement, in order to facilitate network engineers to interact with the network anomaly detection system, enable the "human-in-the-loop" paradigm and refine the detection abilities over time. The major contributions of this document are: the definition of three key stages of the lifecycle process, the definition of a state machine for each anomaly annotation on the system and the definition of YANG data models describing a comprehensive format for the anomaly labels, allowing a well-structured exchange of those between all the interested actors. Network Management (nmrg) ------------------------- "Network Digital Twin: Concepts and Reference Architecture", Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed Boucadair, Christian Jacquenet, 2025-02-28, Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concepts of Network Digital Twin, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. "Research Challenges in Coupling Artificial Intelligence and Network Management", Jerome Francois, Alexander Clemm, Dimitri Papadimitriou, Stenio Fernandes, Stefan Schneider, 2025-03-18, This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, there are many difficult problems in NM that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that networks are operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. "Challenges and Opportunities in Management for Green Networking", Alexander Clemm, Carlos Pignataro, Cedric Westphal, Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini, 2025-03-15, Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they contribute to this footprint themselves in no insignificant way. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become "greener", i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. "Considerations of network/system for AI services", Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Pedro Martinez-Julia, Qin WU, 2025-03-03, As the development of AI technology has matured and AI technology has begun to be applied in various fields, AI technology is changing from running only on very high performance servers to commodity servers with small affordable hardware, including microcontrollers, low performance CPUs, and AI chipsets. This document considers how to configure the network and system in terms of AI inference service to provide AI service in a distributed manner. It also describes the points to consider in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying network-based AI services, such as self-driving vehicles and network digital twins, are described.? "A Framework for LLM-Assisted Network Management with Human-in-the-Loop", Yong Cui, Mingzhe Xing, Lei Zhang, 2025-03-13, This document defines an interoperable framework that facilitates collaborative network management between Large Language Models (LLMs) and human operators. The proposed framework introduces enhanced telemetry module, LLM decision module and standardized interaction data models between human operators and LLM-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. "Use Cases and Practices for Intent-Based Networking", Kehan Yao, Danyang Chen, Jaehoon Jeong, Qin WU, Chungang Yang, Luis Contreras, Giuseppe Fioccola, 2025-03-28, 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. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2025-05-05, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. "An IPv4 Flowlabel Option", Thomas Dreibholz, 2025-03-30, 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. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 2013-02-25, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Deterministic Route Redistribution into BGP", Enke Chen, Jenny Yuan, 2025-05-21, In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. To eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. Additionally, We recommend automatically lowering the LOCAL_PREF value in implementation for the redistributed backup route when appropriate. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2025-03-30, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 2025-03-30, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2025-03-30, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 2025-03-30, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Considerations for Information Services and Operator Services Using SIP", John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell, 2011-08-15, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. "Handle Resolution Option for ASAP", Thomas Dreibholz, 2025-03-30, This document describes the Handle Resolution option for the ASAP protocol. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 2025-03-30, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 2025-03-30, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD)", Palanivelan Appanasamy, 2011-11-17, This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 2010-03-23, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen, 2025-03-17, The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. "Clarification of Proper Use of "@" (at sign) in URI-style Components", Robert Simpson, 2010-07-30, Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14, This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 2025-03-30, This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 2025-03-30, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010", Stephen Slevinski, Valerie Sutton, 2011-01-03, For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen, 2025-06-06, FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that has been widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. "Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi Kawamura, Randy Bush, Cristel Pelsser, 2012-06-21, BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping. "Unified User-Agent String", Mateusz Karcz, 2014-11-10, User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use. "SNMPD to use cache and shared database based on MIB Classification", Haresh Khandelwal, 2012-03-29, This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. "Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya Murakami, Simon Perreault, 2013-05-17, This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. "NAT traversal for LISP", Damien Saucez, Luigi Iannone, Vina Ermagan, Dino Farinacci, Darrel Lewis, Fabio Maino, Marc Portoles-Comeras, Jesper Skriver, Chris White, Albert Bresco, 2025-03-12, This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a Network Address Translator (NAT) device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina Tsou, Simon Perreault, Jing Huang, 2013-09-16, An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. "Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan, 2012-08-02, This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. "The application/stream+json Media Type", James Snell, 2012-10-11, This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. "Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 2012-10-15, This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. "I-PAKE: Identity-Based Password Authenticated Key Exchange", Hyojin Yoon, Sang Kim, 2013-05-03, Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. "remoteStorage", Michiel de Jong, F. Kooman, Sebastian Kippe, 2025-06-11, This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. "Ruoska Encoding", Jukka-Pekka Makela, 2013-10-12, This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. "ICANN Registry Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2025-04-15, This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. "Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol", Nicholas Wilson, 2013-10-07, The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. "Metadata Query Protocol", Ian Young, 2025-01-07, This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. "Ideas for a Next Generation of the Reliable Server Pooling Framework", Thomas Dreibholz, 2025-03-30, This document collects some idea for a next generation of the Reliable Server Pooling framework. "Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol", Walter Hoehlhubmer, 2013-11-25, This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. "Generic Fault-Avoidance Routing Protocol for Data Center Networks", Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish, 2025-01-06, This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. "SAML Profile for the Metadata Query Protocol", Ian Young, 2025-01-07, This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.23. "Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", Xian Zhang, Haomian Zheng, Oscar de Dios, Victor Lopez, Yunbin Xu, 2025-01-13, Resource sharing in a network means two or more Label Switched Paths (LSPs) use common pieces of resource along their paths. This can help save network resources and is useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is responsible for path computation with such requirement. Existing extensions to the Path Computation Element Protocol (PCEP) allow one path computation request for an LSP to be associated with other (existing) LSPs through the use of the PCEP Association Object. This document extends PCEP in order to support resource-sharing-based path computation as another use of the Association Object to enable better efficiency in the computation and in the resultant paths and network resource usage. "Just because it's an Internet-Draft doesn't mean anything... at all...", Warren Kumari, 2025-03-31, Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "A JSON Encoding for HTTP Field Values", Julian Reschke, 2025-04-29, This document establishes a convention for use of JSON-encoded field values in new HTTP fields. "Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)", Thomas Dreibholz, 2025-03-30, This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. "TCP SYN Extended Option Space Using an Out-of-Band Segment", Joseph Touch, Ted Faber, 2025-05-31, This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. "Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix", Naoki Matsuhira, 2025-04-13, 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", Naoki Matsuhira, 2025-04-13, 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)", Naoki Matsuhira, 2025-04-14, 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)", Naoki Matsuhira, 2025-04-14, 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)", Naoki Matsuhira, 2025-04-14, 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)", Naoki Matsuhira, 2025-04-14, 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)", Naoki Matsuhira, 2025-04-14, 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. "Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E)", Naoki Matsuhira, 2025-04-14, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2025-04-13, 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. "TLS 1.2 Update for Long-term Support (LTS)", Peter Gutmann, 2025-02-17, This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2025-04-13, 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. "OpenPGP Web Key Directory", Werner Koch, 2025-06-02, This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. "PCEP Extension for Distribution of Link-State and TE Information for Optical Networks", Yang Zhao, Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin Yoon, 2025-01-13, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. "Fast HIP Host Mobility", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2025-06-08, This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. "MISP core format", Alexandre Dulaunoy, Andras Iklody, 2024-12-31, This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. "MISP taxonomy format", Alexandre Dulaunoy, Andras Iklody, 2024-12-30, This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. "Encapsulating IPsec ESP in UDP for Load-balancing", Xiaohu Xu, Shraddha Hegde, Boris Pismenny, Dacheng Zhang, Liang Xia, Mahendra Puttaswamy, 2025-04-10, IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic. "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff Tantsura, 2025-01-06, BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features. "Adaptive IPv4 Address Space", Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe, 2024-12-23, This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. "BGP Logical Link Discovery Protocol (LLDP) Peer Discovery", Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu, 2025-01-05, Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. "NEAT Sockets API", Thomas Dreibholz, 2025-03-17, This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. "IPv6 is Classless", Nicolas Bourbaki, 2025-03-31, Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu, 2025-03-23, Although several contemporary IT devices have multiple network interfaces, communication sessions are restricted to use only one of them at a time due to the design of the TCP/IP protocol stack: the communication endpoint is identified by an IP address and a TCP or UDP port number. The simultaneous use of these multiple interfaces for a communication session would improve user experience through higher throughput and improved resilience to network failures. MPT is a network layer multipath solution, which provides a tunnel over multiple paths using the GRE-in-UDP specification, thus being different from both MPTCP and Huawei's GRE Tunnel Bonding Protocol. MPT can also be used as a router, routing the packets among several networks between the tunnel endpoints, thus establishing a multipath site-to-site connection. The version of tunnel IP and the version of path IP are independent from each other, therefore MPT can also be used for IPv6 transition purposes. "Reassignment of System Ports to the IESG", Mirja Kuehlewind, Sabrina Tanamal, 2020-02-10, In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate. "A YANG Data Model for Client-layer Tunnel", Chaode Yu, Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2025-04-14, 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. "CoAP: Non-traditional response forms", Carsten Bormann, Christian Amsuess, 2025-03-03, 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. These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated. "HTTP Live Streaming 2nd Edition", Roger Pantos, 2025-02-17, This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 12 of this protocol. "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin Cantrell, 2025-04-01, This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. "A feature freezer for the Concise Data Definition Language (CDDL)", Carsten Bormann, 2025-02-28, In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. "IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2025-01-19, This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. "ICANN Registrar Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2025-04-15, This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. "Flexible Session Protocol", Jun-an Gao, 2025-04-22, FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management "Discovery of OSCORE Groups with the CoRE Resource Directory", Marco Tiloca, Christian Amsuess, Peter van der Stok, 2025-03-03, Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola, Yisong Liu, Mauro Cociglio, Ran Pang, Lixia Xiong, Shinyoung Lee, Weidong Li, 2025-06-03, This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. "PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2025-03-02, The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated, and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. "OAM for Service Programming with Segment Routing", Zafar Ali, Clarence Filsfils, Francois Clad, Xiaohu Xu, 2025-03-03, This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. "Uberlay Interconnection of Multiple LISP overlays", Victor Moreno, Dino Farinacci, Alberto Rodriguez-Natal, Marc Portoles-Comeras, Fabio Maino, Sanjay Hooda, 2025-04-07, This document describes the use of the Locator/ID Separation Protocol (LISP) to interconnect multiple disparate and independent network overlays by using a transit overlay. The transit overlay is referred to as the "uberlay" and provides connectivity and control plane abstraction between different overlays. Each network overlay may use different control and data plane approaches and may be managed by a different organization. Structuring the network into multiple network overlays enables the interworking of different overlay approaches to data and control plane methods. The different network overlays are autonomous from a control and data plane perspective, this in turn enables failure survivability across overlay domains. This document specifies the mechanisms and procedures for the distribution of control plane information across overlay sites and in the uberlay as well as the lookup and forwarding procedures for unicast and multicast traffic within and across overlays. The specification also defines the procedures to support inter-overlay mobility of EIDs and their integration with the intra-overlay EID mobility procedures defined in draft-ietf-lisp-eid-mobility. "General Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw, 2025-05-01, This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. "Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX", Donald Eastlake, Bob Briscoe, Shunwan Zhuang, Andrew Malis, Xinpeng Wei, 2025-04-02, Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde, 2025-04-25, Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. "Modern Network Unicode", Carsten Bormann, 2025-03-02, BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. "The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency", Bob Briscoe, Greg White, 2023-11-23, This informational document explains the specification of the queue protection algorithm used in DOCSIS technology since version 3.1. A shared low latency queue relies on the non-queue-building behaviour of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the queue protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low latency queue by ejecting selected packets (or all packets) of these flows. The document is designed for four types of audience: a) congestion control designers who need to understand how to keep on the 'good' side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm. "Software Version Capability for BGP", Donatas Abraitis, 2025-01-10, In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. "Maintaining CCNx or NDN flow balance with highly variable data object sizes", David Oran, 2025-03-31, Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. "OpenPGP Example Keys and Certificates", Bjarni Einarsson, "juga", Daniel Gillmor, 2025-05-08, The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. "Prefix Unreachable Announcement", Aijun Wang, Zhibo Hu, Jinsong Sun, Changwang Lin, 2025-05-26, This document describes a mechanism that can trigger the switchover of the services which rely on the reachability of the peer endpoints, for example the BGP or the tunnel services. It is mainly used in the scenarios that the summary prefixes are advertised at the border routers whereas the services endpoints are located in different IGP areas or levels, whose reachabilities are covered by the summary prefixes. It introduces a new signaling mechanism using a negative prefix announcement called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the overlay services that the communication endpoint is unreachabe to force the overlay service headend switchover immediately. "Lzip Compressed Format and the 'application/lzip' Media Type", Antonio Diaz, 2025-01-01, Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. "PEM file format for ECH", Stephen Farrell, 2025-06-01, Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. "Stateless OpenPGP Command Line Interface", Daniel Gillmor, 2025-05-08, This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. "A YANG Data Model for Client Signal Performance Monitoring", Chaode Yu, Haomian Zheng, Italo Busi, Zheng Yanlei, Victor Lopez, Oscar de Dios, 2025-03-03, A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. "Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang, Aijun Wang, Shunwan Zhuang, 2025-01-13, BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. "(Deprecated) Protected E-mail Headers", Bjarni Einarsson, "juga", Daniel Gillmor, 2025-04-16, This is a tombstone document of an abandoned effort to provide end- to-end cryptographic protections for e-mail headers. It has been superseded by draft-ietf-lamps-header-protection "Operational Considerations for BRSKI Registrar", Michael Richardson, Wei Pan, 2025-01-22, This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. "Operational Considerations for Voucher infrastructure for BRSKI MASA", Michael Richardson, Wei Pan, 2025-01-22, This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. "Resource Allocation Model for Hybrid Switching Networks", Weiqiang Sun, Junyi Shao, Weisheng Hu, 2025-06-01, The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. "Approaches on Supporting IOAM in IPv6", Haoyu Song, Zhenbin Li, Shuping Peng, Jim Guichard, 2025-02-17, IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. "An Algorithm for Computing Dynamic Flooding Topologies", Sarah Chen, Tony Li, 2025-01-26, Link-state routing protocols suffer from excessive flooding in dense network topologies. RFC 9667, "Dynamic Flooding on Dense Graphs", alleviates the problem by decoupling the flooding topology from the physical topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the physical topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used as a flooding topology in dynamic flooding. This document discloses the algorithm that we have developed in order to make it easier for other developers to implement similar algorithms. We do not claim that our algorithm is optimal, rather it is a pragmatic effort and we expect that further research and refinement can improve the results. We are not proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work, however we have no objections if the working group chooses to do so. "Crowd Sourced Remote ID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Shuai Zhao, Henk Birkholz, 2025-04-08, 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. "UAS Operator Privacy for RemoteID Messages", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2025-03-18, This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. "Notable CBOR Tags", Carsten Bormann, 2025-02-12, The Concise Binary Object Representation (CBOR, RFC 8949) 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. "MAC Address for Layer 3 Link Local Discovery Protocol (LLDP)", Donald Eastlake, 2025-06-11, IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. "Trusted Path Routing", Henk Birkholz, Eric Voit, Peter Liu, Diego Lopez, Meiling Chen, 2025-01-08, There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. "Distributed Ledger Time-Stamp", Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano, 2025-05-25, This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. "pretty Easy privacy (pEp): Email Formats and Protocols", Hernani Marques, Bernie Hoeneisen, 2025-05-22, The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (such as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption viable for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). "YANG Data Model for MPLS LSP Ping", Nagendra Nainar, Madhan Sankaranarayanan, Jaganbabu Rajamanickam, Carlos Pignataro, Guangying Zheng, 2025-05-22, This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. "Cacheable OSCORE", Christian Amsuess, Marco Tiloca, 2025-01-08, Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. "SVG Tiny Portable/Secure", Alex Brotman, J. Adams, 2025-05-01, This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER", Ran Chen, BenChong Xu, Huaimo Chen, Aijun Wang, 2025-03-03, This draft specify a new mechanism where PCE allocates the BIER information centrally and uses PCEP to distribute them to all nodes, then PCC generate a "Bit Index Forwarding Table"(BIFT). "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE", Ran Chen, BenChong Xu, Huaimo Chen, Aijun Wang, 2025-03-03, 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). "MSYNC", Sophie Bale, Remy Brebion, Guillaume Bichot, 2025-05-28, This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. "Binary Application Record Encoding (BARE)", Drew DeVault, 2025-04-25, 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). "Handling and Adoption of Internet-Drafts by IETF Working Groups", Adrian Farrel, Dave Crocker, Brian Carpenter, Fernando Gont, Michael Richardson, 2025-03-23, The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. "DC aware TE topology model", Luis Contreras, Xufeng Liu, 2025-03-03, This document proposes the extension of the TE topology model for including information related to data center resource capabilities. "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting", Steven Jones, Alessandro Vesely, 2025-04-11, 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. "SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li, 2025-02-26, This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. "A taxonomy of eavesdropping attacks", Michael Richardson, Jonathan Hoyland, 2024-12-22, The terms on-path attacker and MITM Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. Increasingly people have become uncomfortable with the gendered term "Man" in the middle and have sought alternatives. This document offers an update on terminology for network attacks, retaining some acronyms terms while redefining the expansion, and clarifying the different kinds of attacks. Consistent terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. "Application of the Alternate Marking Method to the Segment Routing Header", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang, 2025-06-06, The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative experimental approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. The experiment is to determine whether those benefits are significant and attractive to the community: if they are, the work may be brought back for IETF consideration. This protocol extension has been developed outside the IETF as an alternative to the IETF’s standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. "PCEP Extensions for sid verification for SR-MPLS", Ran Chen, Samuel Sidor, Chun Zhu, Zoey Rose, Mike Koldychev, 2025-06-02, This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. "Layer-3 Accessible EVPN Services", Wei Wang, Aijun Wang, Haibo Wang, 2025-02-28, This draft describes layer-3 accessible EVPN service interfaces, which aim is to connect the layer 2 customers to one EVPN backbone, via the layer 3 network, and keep the traffic isolation among different layer 2 customers. It proposes to extend the VxLAN packet format to transfer the customer's Virtual Network Identifier(VNI) information, and also the related control plane extension. "Carrying NRP related Information in MPLS Packets", Zhenbin Li, Jie Dong, 2025-02-13, 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. Multiple NRPs can be created by network operator to meet the diverse requirements of enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used as the NRP Selector to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the NRP Selector ID and related information in MPLS packets. The procedure for processing the NRP Selector ID and related information is also specified. "Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation", Carsten Bormann, 2025-04-23, 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, but was deemed useful to obtain initial feedback on the approach taken. "Security Technical Specification for Smart Devices of IoT", Bin Wang, Xing Wang, Li Wan, Wenyuan Xu, Chonghua Wang, HaoNan Yan, Yinghui Xie, 2025-05-20, As IoT adoption accelerates, securing smart devices emerges as a critical priority. This proposal outlines a comprehensive security framework spanning hardware integrity, system reliability, data protection, network safeguards, and management controls. The framework mandates secure hardware interfaces, firmware validation mechanisms, robust data encryption protocols, encrypted communication channels, and systematic security auditing processes to ensure end- to-end protection across device ecosystems. "Technical Requirements for Secure Access and Management of IoT Smart Terminals", Bin Wang, Song Liu, Li Wan, Jun Li, Xing Wang, HaoNan Yan, Yinghui Xie, 2025-05-20, This specification outlines technical requirements for IoT smart terminal access management to address critical security challenges. The widely dispersed nature of IoT devices (including IP cameras, access control systems, and traffic monitoring units) complicates effective oversight while creating significant vulnerabilities during network authentication. The proposed framework combats unauthorized access and device impersonation through enhanced access control mechanisms, enabling real-time device monitoring and prompt detection of offline status - essential capabilities for maintaining secure and stable IoT network operations. "Open Service Access Protocol for IoT Smart Devices", Bin Wang, Shaopeng Zhou, Chao Li, Chunming Wu, Zizhao Wang, HaoNan Yan, Yinghui Xie, 2025-05-20, The proliferation of IoT technology has led to ubiquitous interconnectivity across devices and systems. However, industry-wide challenges persist due to heterogeneous data formats, incompatible device protocols, and fragmented service interfaces across IoT ecosystems. This technical specification establishes standardized communication protocols and control interfaces for IoT devices, targeting system design, testing, and interoperability research. By implementing a structured open service interconnection framework, it aims to streamline cross-system integration while reducing implementation redundancy and breaking down service barriers, ultimately accelerating industrial IoT advancement. "Fetch and Validation of Verified Mark Certificates", Wei Chuang, Marc Bradshaw, Thede Loder, Alex Brotman, 2025-05-01, A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. "BIMI Reporting", J. Adams, Alex Brotman, 2025-05-01, To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. "Data Transmission Security of Identity Resolution in Industrial Internet", Bin Wang, Kezhang Lin, Chonghua Wang, Xing Wang, HaoNan Yan, Yinghui Xie, 2025-05-20, This draft examines data transmission security in Industrial Internet identity resolution systems. As pivotal infrastructure enabling secure cross-organizational sharing and intelligent correlation of heterogeneous data, these systems require robust security services during resolution processes. The analysis focuses on essential protective measures for identity resolution operations. "Security for the NFSv4 Protocols", David Noveck, 2025-05-16, This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the use of Access Control Lists, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881. "EVPN multi-homing support for L3 services", Michael MacKenzie, Patrice Brissette, Satoru Matsushima, Wen Lin, Jorge Rabadan, 2025-05-09, This document introduces the utilization of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to enhance network availability and load balancing for various L3 services in EVPN. "Encoding Network Slice Identification for SRv6", Weiqiang Cheng, Peiyong Ma, Fenghua Ren, Changwang Lin, Liyan Gong, Shay Zadok, Mingyu Wu, xuewei wang, 2025-01-02, 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. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. "Service Function Chaining (SFC) Parallelism and Diversions", Donald Eastlake, 2025-05-05, 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. "RUSH - Reliable (unreliable) streaming protocol", Kirill Pugin, Nitin Garg, Alan Frindell, Jorge Ferret, Jake Weissman, 2025-04-21, RUSH is an application-level protocol for ingesting live video. This document describes the protocol and how it maps onto QUIC. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/afrind/draft-rush. "Security and Privacy Considerations for Multicast Transports", Kyle Rose, Max Franke, Jake Holland, 2025-05-07, 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. "Transient Hiding of Hop-by-Hop Options", Donald Eastlake, Jie Dong, 2025-06-08, There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. "KEM-based Authentication for TLS 1.3", Thom Wiggers, Sofia Celi, Peter Schwabe, Douglas Stebila, Nick Sullivan, 2025-04-22, This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. "MTU propagation over EVPN Overlays", DIKSHIT Saumya, Vinayak Joshi, A Nayak, 2025-02-02, Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. "Defreezing Optimization post EVPN Mac Dampening", DIKSHIT Saumya, Vinayak Joshi, Swathi Shankar, 2025-01-08, MAC move handling in EVPN deployments is discussed in detail in [RFC7432]. There are few optimizations which can be done in existing way of handling the mac duplication. This document describes few of the potential techniques to do so. This document is of informational type based on comments in the ietf meeting. "All PEs as DF", DIKSHIT Saumya, Vinayak Joshi, 2025-01-08, The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. "Extending ICMPv6 for SRv6-related Information Validation", Yao Liu, Yisong Liu, 2025-02-25, 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. "Procedure for Standards Track Documents to Refer Normatively to External Documents", Murray Kucherawy, 2024-05-08, This document specifies a procedure for referencing external standards and specifications from IETF-produced documents on the Standards Track. In doing so, it updates BCP 9 (RFC 2026). "Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter", Quan Xiong, Shaofu Peng, Vishnu Beeram, Tarek Saad, Mike Koldychev, 2025-05-28, This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter during path computation. "Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, Alex Brotman, 2025-06-16, 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. "A UDP-based GMA (Generic Multi-Access) Protocol", Jing Zhu, Menglei Zhang, Sumit Roy, 2025-03-03, A device can simultaneously connect to multiple access networks, e.g., Wi-Fi, LTE, 5G, DSL, and SATCOM (Satellite Communications). It is desirable to seamlessly combine multiple connections over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built-in multi- path capabilities. This document presents a new convergence protocol for managing data traffic across multiple network paths. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations to experiment with the protocol. "Updated Rules for PCE Communication Protocol (PCEP) Object Ordering", Dhruv Dhody, 2025-01-05, The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these messages are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. "Unicast Use of the Formerly Reserved 240/4", Seth Schoen, John Gilmore, David Taht, 2024-12-29, This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. "Unicast Use of the Lowest Address in an IPv4 Subnet", Seth Schoen, John Gilmore, David Taht, Michael Karels, 2024-12-29, With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. "Flow Measurement in IPv6 Network", Haojie Wang, Yisong Liu, Changwang Lin, Xiao Min, Greg Mirsky, Jinming Li, 2024-12-29, This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. "Problems and Requirements of Addressing in Integrated Space-Terrestrial Network", Yuanjie Li, Hewu Li, Lixin Liu, Qian Wu, Jun Liu, 2025-06-13, This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. "QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps", Connor Smith, Ian Swett, Joseph Beshay, Sharad Jaiswal, Ilango Purushothaman, Brandon Schlinker, 2025-04-22, This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/wcsmith/draft-quic-receive-ts. "BGP SR Policy Extensions for template", KaZhang, Zhibo Hu, Jie Dong, Qiangzhou Gao, 2024-12-30, Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. "Unicast Use of the Formerly Reserved 0/8", Seth Schoen, John Gilmore, David Taht, 2024-12-29, This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. "Unicast Use of the Formerly Special-Cased 127/8", Seth Schoen, John Gilmore, David Taht, 2024-12-29, This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. "A CoRIM Profile for Arm's Platform Security Architecture (PSA)", Thomas Fossati, Yogesh Deshpande, Henk Birkholz, 2025-03-03, PSA Endorsements include reference values, endorsed values, cryptographic key material and certification status information that a Verifier may need in order to appraise attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. "Control Plane of Source Address Validation Architecture-eXternal (SAVA-X)", Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu, 2025-05-26, Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. "Data Plane of Source Address Validation Architecture-eXternal (SAVA-X)", Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu, 2025-05-26, Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. "Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X)", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2025-05-26, Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. "Open Ethics Transparency Protocol", Nikita Lukianets, 2025-01-26, The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. "IPlir network layer security protocol", Martishina Alexandra, Urivskiy Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia, 2025-03-16, This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. "DHCPv6 Extension Practices and Considerations", Ren Gang, Lin He, Ying Liu, 2024-12-27, IP addresses assume an increasing number of attributes as communication identifiers to meet different requirements. Privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol as required. This document provides current extension practices and typical DHCPv6 server software in terms of extensions, defines a general model of DHCPv6, discusses some extension points, and presents extension cases. "Remote Procedure Call over QUIC Version 1", Benjamin Coddington, Scott Mayhew, Chuck Lever, 2025-05-02, This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. "Deadline Based Deterministic Forwarding", Shaofu Peng, Zongpeng Du, Kashinath Basu, czp@h3c.com, Dong Yang, Chang Liu, 2025-05-21, 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]. "SMTP Enhanced Status Codes for Potentially Unwanted Mail", Alex Brotman, 2025-03-03, We define a method by which an SMTP receiver can immediately notify a sender that their message is suspected to be unwanted, although it may still be accepted. "IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension", Daiying Liu, Daniel Migault, Renwang Liu, Congjie Zhang, 2025-03-03, 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. "Using CDDL for CSVs", Carsten Bormann, Henk Birkholz, 2025-03-03, The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. "SRPM Path Consistency over SRv6", sijun weng, Weiqiang Cheng, Changwang Lin, Xiao Min, Jinming Li, 2024-12-29, TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light. "IETF Network Slice Service Mapping YANG Model", Dhruv Dhody, Bo Wu, 2025-01-29, 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. "pretty Easy privacy (pEp): Privacy by Default", Volker Birk, Hernani Marques, Bernie Hoeneisen, 2025-05-22, The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer- to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like data minimization, end-to-end and interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. "Advertisement of Dedicated Metric for Flexible Algorithm in IGP", Changwang Lin, Mengxiao Chen, Weiqiang Cheng, Liyan Gong, 2025-03-18, This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. "dry-run DNSSEC", Yorgos Thessalonikefs, Willem Toorop, Roy Arends, 2025-03-03, This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in a DS record, referred to as dry-run DS, signal to validating resolvers that dry-run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of a dry- run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. "The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record", Donald Eastlake, Haoyu Song, 2025-02-19, A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. "Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks", Sheng Liu, Haomian Zheng, Aihua Guo, Yang Zhao, Daniel King, 2025-04-21, Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. "Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries", Donald Eastlake, Haoyu Song, 2025-03-16, A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses including addressing and packet labeling information that is dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). "BGP Extensions for the Mobile User Plane (MUP) SAFI", Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer, 2025-02-13, This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. "Protocol extension and mechanism for fused service function chain", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Xueshun Wang, Dongping Deng, 2025-02-08, This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. "The Architecture of Network-Aware Domain Name System (DNS)", Haoyu Song, Donald Eastlake, 2025-02-22, This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. "TCP RST Diagnostic Payload", Mohamed Boucadair, Tirumaleswar Reddy.K, Jason Xing, 2025-03-01, This document specifies a diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. "LISP for Satellite Networks", Dino Farinacci, Victor Moreno, Padma Pillay-Esnault, 2025-01-27, This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. "ACME-Based Provisioning of IoT Devices", Michael Sweet, 2025-02-07, This document extends the Automatic Certificate Management Environment (ACME) to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. "SRv6 Egress Protection in Multi-homed scenario", Weiqiang Cheng, Jiang Wenying, Changwang Lin, Zhibo Hu, Yuanxiang Qiu, 2025-06-06, This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. "Dangerous Labels in DNS and E-mail", Daniel Gillmor, 2025-02-03, This document establishes registries that list known security- sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. "Multicast Extension for QUIC", Jake Holland, Lucas Pardue, Max Franke, 2025-01-07, This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. "Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE)", Gyan Mishra, Jeff Tantsura, Mankamana Mishra, Sudha Madhavi, Adam Simpson, Shuanglong Chen, 2025-03-03, 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. "EVPN Mpls Ping Extension", DIKSHIT Saumya, Gyan Mishra, Srinath Rao, Santosh Easale, Ashwini Dahiya, 2025-05-26, In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. "Path Tracing in SR-MPLS networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Israel Meilik, Mike Valentine, Ruediger Geib, Jonathan Desmarais, 2025-05-11, Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. "Extended relation information for Semantic Definition Format (SDF)", Petri Laari, 2025-01-28, The Semantic Definition Format (SDF) base specification defines set of basic information elements that can be used for describing a large share of the existing data models from different ecosystems. While these data models are typically very simple, such as basic sensors definitions, more complex models, and in particular bigger systems, benefit from ability to describe additional information on how different definitions relate to each other. This document specifies an extension to SDF for describing complex relationships in class level descriptions. This specification does not consider instance- specific information. "Extensible In-band Processing (EIP) Architecture and Framework", Stefano Salsano, Hesham ElBakoury, Diego Lopez, 2025-01-04, Extensible In-band Processing (EIP) extends the functionality of the IPv6 protocol considering the needs of future Internet services / 6G networks. This document discusses the architecture and framework of EIP. Two separate documents respectively analyze a number of use cases for EIP and provide the protocol specifications of EIP. "REST API Linked Data Keywords", Roberto Polli, 2025-04-23, This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. "Asynchronous Deterministic Networking Framework for Large-Scale Networks", Jinoo Joung, Jeong-dong Ryoo, Taesik Cheung, Yizhou Li, Peng Liu, 2025-03-16, This document describes various solutions of Asynchronous Deterministic Networking (ADN) for large-scale networks. The solutions in this document do not need strict time-synchronization of network nodes, while guaranteeing end-to-end latency or jitter. The functional architecture and requirements for such solutions are specified. "Secure IP Binding Synchronization via BGP EVPN", DIKSHIT Saumya, Gadekal, Reddy, 2025-02-02, The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. "NRP ID in SRv6 segment", Yisong Liu, Changwang Lin, Hao Li, Liyan Gong, 2025-06-06, This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. "IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID", Changwang Lin, Mengxiao Chen, Hao Li, 2025-06-06, The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. "IGP Extensions for Advertising Node Index", Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2025-03-29, This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. "IGP Extensions for Advertising Link Numbers", Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2025-03-29, This document describes OSPF and IS-IS extensions for distributing the link numbers assigned to the links originating at a node. "Stateless Best Effort Multicast Using MRH", Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu, 2025-03-29, This document describes stateless best effort Multicast along the shortest paths to the egress nodes of a P2MP Path/Tree. The multicast data packet is encapsulated in an IPv6 Multicast Routing Header (MRH). The MRH contains the egress nodes represented by the indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along the shortest path. There is no state stored in the core of the network. "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Hannes Tschofenig, Yaron Sheffer, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, Arto Niemi, Thomas Fossati, 2025-04-30, The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. "A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information", Donald Eastlake, Haoyu Song, 2025-04-15, 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. "Multi-Topology in PIM", Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli, 2025-04-13, 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", Rohan Mahy, 2025-03-03, 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. "Problem statement for Inter-domain Intent-aware Routing using Color", Shraddha Hegde, Dhananjaya Rao, Jim Uttaro, Alex Bogdanov, Luay Jalil, 2025-01-31, This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions. "A Larger Internet Key Exchange version 2 (IKEv2) Payload", Yoav Nir, 2025-03-16, The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document defines an extension to IKEv2 that allows larger payloads. "Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)", Greg Mirsky, Li Zhang, Loa Andersson, 2025-02-28, Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. "The Transit Measurement Option", Tal Mizrahi, Tianran Zhou, Shahar Belkar, Reuven Cohen, 2025-01-07, This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. "Cisco's CoAP Simple Management Protocol", Paul Duffy, 2025-06-13, CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. "The R5N Distributed Hash Table", Martin Schanzenbach, Christian Grothoff, Bernd Fix, 2025-03-17, This document contains the R^5N DHT technical specification. R^5N is a secure distributed hash table (DHT) routing algorithm and data structure for decentralized applications. It features an open peer- to-peer overlay routing mechanism which supports ad-hoc permissionless participation and support for topologies in restricted-route environments. Optionally, the paths data takes through the overlay can be recorded, allowing decentralized applications to use the DHT to discover routes. This document defines the normative wire format of protocol messages, routing algorithms, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to guide implementation of R^5N and to ensure interoperability among implementations including the pre-existing GNUnet implementation. "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", Michael Tuexen, Randall Stewart, 2025-03-02, This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality needed within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. It obsoletes RFC 6951. "SCION Control Plane PKI", Corine de Kater, Nicola Rustignoli, Samuel Hitz, 2025-03-03, This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture where the Control Plane PKI handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's Control Plane to authenticate and verify path information, and provisions SCION's trust model based on Isolation Domains. This document describes the trust model behind the SCION Control Plane PKI, including specifications of the different types of certificates and the Trust Root Configuration. It also specifies how to deploy the Control Plane PKI infrastructure. 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. "Distributed Flow Measurement in IPv6", Haojie Wang, Jinming Li, Changwang Lin, Xiao Min, Greg Mirsky, 2024-12-29, In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller. "Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets", Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren, Fan Yang, 2025-03-03, 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. "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", David Noveck, 2025-05-23, This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It includes protocol extensions made as part of the respecification effort for NFS Minor Version 1. It obsoletes and replaces RFC5662. "Template-Driven HTTP Request Proxying", Benjamin Schwartz, 2025-05-02, HTTP request proxying behaviors have long been part of the core HTTP specification. However, the core request proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative proxy service configuration for HTTP requests. The proxy service is identified by a URI Template, similarly to "connect-tcp" and "connect-udp". "The Incident Detection Message Exchange Format version 2 (IDMEFv2)", Gilles Lehmann, 2025-04-01, The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. "Mappings Between XML2RFC v3 and AsciiDoc", Marc Petit-Huguenin, 2025-01-26, This document specifies a mapping between XML2RFC v3 and AsciiDoc. The goal of this mapping and its associated tooling is to make writing an Internet-Draft as simple as possible, by converting any AsciiDoc formatted document into a valid Internet-Draft, ready to be submitted to the IETF. This is still work in progress and for the time being this mapping only ensures that any valid XML2RFC element can be generated from AsciiDoc. "A Concise Binary Object Representation (CBOR) of DNS Messages", Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch, 2025-04-16, 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. "CDDL 2.0 and beyond -- a draft plan", Carsten Bormann, 2025-02-28, The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and draft-ietf-cbor-cddl-more-control (RFC-to-be 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. "NTRU Key Encapsulation", Scott Fluhrer, Michael Prorock, Sofia Celi, John Gray, Xagawa Keita, Haruhisa Kosuge, 2025-03-03, This draft document provides recommendations for the implementation of a post-quantum Key Encapsulation Mechanism (KEM) scheme based on the NTRU encryption scheme. The KEM is an existing cryptographic system; no new cryptography is defined herein. The well-defined and reviewed parameter sets for the scheme are defined and recommended. The test vectors are also provided. "LSP Ping/Traceroute for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, Loa Andersson, 2025-03-31, This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in MPLS networks. The MPLS Node IOAM Information Query functionality uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. "Encapsulation of BFD for SRv6 Policy", Yisong Liu, Weiqiang Cheng, Changwang Lin, Xiao Min, 2025-06-06, Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. "MoQ relays for Support of High-Throughput Low-Latency Traffic in 5G", Xavier de Foy, Renan Krishna, Tianji Jiang, 2025-02-28, This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MoQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MoQ that is equivalent to what is possible for RTP. "Stateless Best Effort Multicast Simulations", Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu, 2025-03-29, This document describes simulations of stateless best effort Multicasts and lists a set of simulation results for different large network sizes and different tree sizes. "Scenarios and Protocol Extension Requirements of a Generalized IPv6 Tunnel", Xinxin Yi, Zhenbin Li, Qiangzhou Gao, Bing Liu, Tianran Zhou, Shuping Peng, 2025-03-03, IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Network Slicing, Alternate Marking, iOAM, DetNet etc. In some networks, the operators might want to leverage these new features but since the network system still using some lagecy encapsulations other than IPv6 (e.g. VxLAN, GRE etc.), these features are just not applicable for them. This document introduces some cases of such scenarios, and discusses the potential requirement of defining a new Generalized IPv6 Tunnel (GIP6). With GIP6, all the additional functions defined as IPv6 extension headers could be easily supported, so that the legacy encapsulations could migrate to a unified solution rather than sccaterred upgrade in each legacy technologies, which is heavy burden for the industry. Considering network devices have different capabilities of IPv6 extension header processing, this document also analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. "BGP-LS Advertisement of TE Policy Performance Metric", Changwang Lin, Yisong Liu, Yongqing Zhu, 2025-03-02, This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). "EVPN Multicast Forwarding for EVPN to EVPN Gateways", Jorge Rabadan, Olivier Dornon, Vinod Prabhu, Alex Nichol, Zhaohui Zhang, Wen Lin, 2025-03-03, 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. "Intent-Based Network Management Automation in 5G Networks", Jaehoon Jeong, Yoseop Ahn, Mose Gu, Younghan Kim, J., PARK, 2025-06-09, This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). "SR Policy Group", Weiqiang Cheng, Jiang Wenying, Changwang Lin, Yuanxiang Qiu, Yawei Zhang, Ran Chen, Yanrong Liang, 2025-02-28, 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 describes SR policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR policy and SR Policy Group to provide best practice cases for operators "ISP Dual Queue Networking Deployment Recommendations", Jason Livingood, 2025-04-24, The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores the potential implications of those decisions and makes recommendations that can help drive adoption and acceptance of L4S and NQB. "BGP over QUIC", Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura, 2025-01-07, This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. "INIT Forwarding for the Stream Control Transmission Protocol", Michael Tuexen, Timo Voelker, 2025-03-02, The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. "Identity for E2E-Secure Communications", Richard Barnes, Rohan Mahy, 2025-02-04, 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. "Secret Key Agreement for DNS: The TKEY Resource Record", Donald Eastlake, Mark Andrews, 2025-03-02, RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. "The "dereferenceable identifier" pattern", Carsten Bormann, Christian Amsuess, 2025-03-03, In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. // The present revision -04 includes a few clarifications. "Flag-based MPLS Network Actions (MNA) for On-Path Telemetry", Haoyu Song, Giuseppe Fioccola, Rakesh Gandhi, 2025-02-17, This document describes the support of two flag-based variants of on- path Telemetry techniques, Postcard-Based On-Path Telemetry (PBT) and Alternate Marking (AM), as MPLS Network Actions (MNA)for OAM in MPLS networks. The scheme only uses a few bits in the MNA header opcode dedicated for the flag-based actions. "Testing async submission", Robert Sparks, 2025-06-13, This draft is submitted only to test the async api submission endpoint "The Gordian Envelope Structured Data Format", Wolf McNally, Christopher Allen, 2025-03-29, Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. "A Pre-Authentication Mechanism for SSH", Peter Gutmann, 2025-02-17, Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. "An Ontology for RFCs", Marc Petit-Huguenin, 2025-01-19, This document defines an ontology that describes the specifications published by the RFC Editor, together with ancillary documents. "The "_for-sale" Underscored and Globally Scoped DNS Node Name", Marco Davids, 2025-06-03, This document defines an operational convention for using the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. This approach offers the advantage of easy deployment without affecting ongoing operations. As such, the method can be applied to a domain name that is still in full use. Note to the RFC Editor This document contains several "Notes to the RFC Editor", including this section. These should be reviewed and resolved prior to publication. "Interconnecting domains with IBGP", Krzysztof Szarkowicz, Moshiko Nayman, Israel Means, 2024-12-17, This document relaxes the recommendations specified in BGP/MPLS IP Virtual Private Networks (VPNs) and BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) allowing the building of Inter-domain L3VPN architecture with internal BGP. "Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol", Marc Blanchet, 2025-03-31, This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. "Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol", Marc Blanchet, 2025-03-31, This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. "lispers.net LISP NAT-Traversal Implementation Report", Dino Farinacci, 2025-06-02, This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. "Computerate Specification", Marc Petit-Huguenin, 2025-05-04, This document specifies computerate specifications, which are the combination of a formal and an informal specification such as parts of the informal specification are generated from the formal specification. "Compressed SID (CSID) for SRv6 SFC", Cheng Li, Weiqiang Cheng, Hongyi Huang, 2025-04-22, 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. "Timeslot Queueing and Forwarding Mechanism", Shaofu Peng, Peng Liu, Kashinath Basu, Aihua Liu, Dong Yang, Guoyu Peng, 2025-04-08, 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, which we call 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. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2025-01-19, This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes RFC 9231. "IP Addressing with References (IPREF)", Waldemar Augustyn, 2025-03-17, IP addressing with references, or IPREF for short, is a method for end-to-end communication across different address spaces normally not reachable through native means. IPREF uses references to addresses instead of real addresses. It allows to reach across NAT/NAT6 and across protocols IPv4/IPv6. It is a pure layer 3 addressing feature that works with existing network protocols. IPREF forms addresses (IPREF addresses) made of context addresses and references. These IPREF addresses are publishable in Domain Name System (DNS). Any host in any address space, including behind NAT/ NAT6 or employing different protocol IPv4/IPv6, may publish IPREF addresses of its services in DNS. These services will be reachable from any address space, including those running different protocol IPv4/IPv6 or behind NAT/NAT6, provided both ends support IPREF. IPREF is especially useful for transitioning to IPv6 or for operating networks with a mix of IPv4/IPv6. "Managing CBOR codepoints in Internet-Drafts", Carsten Bormann, 2025-03-01, CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. "Distribution of Service Metadata in BGP-LS", Cheng Li, Hang Shi, Tao He, Ran Pang, Guofeng Qian, 2025-04-14, 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. "Distribution of SR P2MP Policies and State using BGP-LS", Yisong Liu, Changwang Lin, Hooman Bidgoli, Zheng Zhang, 2025-03-27, This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. "Distribution of Service Metadata in BGP FlowSpec", Xinxin Yi, Tao He, Cheng Li, Hang Shi, Xiangfeng Ding, Haibo Wang, Zicheng Wang, 2025-05-15, 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 IP address. Its routes along with service metadata can be collected by a central controller. The controller may process the metadata and distribute the result to ingress routers using BGP FlowSpec. The service metadata can be used by ingress routers to make path selections not only based on the routing cost but also on the running environment of the edge services. This document describes a mechanism to distribute the information of the service routes and related service metadata using BGP FlowSpec. "CDDL models for some existing RFCs", Carsten Bormann, 2025-02-23, A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. "BGP Flow-Spec Traffic Compress Action", Ming Shen, Wenyan Li, Lili Wang, Guoqiang Wang, 2025-02-28, Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. This document specifies a new traffic filtering action to support compressing traffic. "Flexible Candidate Path Selection of SR Policy", Yisong Liu, Changwang Lin, Shuping Peng, Ran Chen, Gyan Mishra, Yuanxiang Qiu, 2025-03-03, This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. "the extensions of BGP-LS to carry security capabilities", Meiling Chen, Li Su, 2025-03-03, The BGP-LS protocol is extended to carry the security capabilities of the node. The controller collects topology information, forms a topology path with security capabilities according to security requirements, and supports SRv6 path sending to execute node forwarding through programming. "IGP Color-Aware Shortcut", Weiqiang Cheng, Liyan Gong, Changwang Lin, Ran Chen, 2025-04-01, 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. "dCBOR: A Deterministic CBOR Application Profile", Wolf McNally, Christopher Allen, Carsten Bormann, Laurence Lundblade, 2025-02-07, The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The CBOR Common Deterministic Encoding (CDE) Internet Draft builds on this by specifying a baseline for application profiles that wish to implement deterministic encoding with CBOR. The present document provides an application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding based on CDE for a variety of applications wishing an even narrower and clearly defined set of choices. "The DNSCrypt Protocol", Frank Denis, 2025-04-15, 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. "BGP extensions for BIER-TE", Ran Chen, Changwang Lin, BenChong Xu, Zheng Zhang, 2025-01-25, "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. This document describes BGP extensions for advertising the BIER-TE specific information. "Source IPv6 Address Programmability", Weiqiang Cheng, Liyan Gong, Changwang Lin, Hao Li, 2025-03-27, 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 "Supplement of BGP-LS Distribution for SR Policies and State", Yao Liu, Shaofu Peng, Zhenqiang Li, 2025-02-20, This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags are introduced in SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. "EVPN Inter-Domain Option-B Solution", Jorge Rabadan, Senthil Sathappan, Ali Sajassi, Wen Lin, 2025-03-03, An EVPN Inter-Domain interconnect solution is required if two or more sites of the same Ethernet Virtual Private Network (EVPN) are attached to different IGP domains or Autonomous Systems (AS), and they need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for such EVPN connectivity. While multiple documents refer to this type of interconnect solution and specify different aspects of it, there is no document that summarizes the impact of the Inter-Domain Option-B connectivity in the EVPN procedures. This document does not specify new procedures but analyses the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the described issues. Those solutions are based on either other specifications or based on local implementations that do not modify the end-to-end EVPN control plane. "Merkle Tree Certificates for TLS", David Benjamin, Devon O'Brien, Bas Westerbaan, 2025-03-03, This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from trusted mirrors can use this certificate type as a size optimization over more conventional mechanisms with post-quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. "Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP)", Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad, 2025-01-05, This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. "SID as source address in SRv6", Feng Yang, Changwang Lin, 2025-06-16, In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. "Security Considerations for Tenant ID and Similar Fields", Donald Eastlake, Nancy Cam-Winget, Mohammed Umair, 2025-03-30, Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. "Considerations for SRv6 across Untrusted Domain", Changwang Lin, Ce Zhou, Mengxiao Chen, 2025-01-14, Segment Routing operates within a trusted domain. There are some scenarios in which the whole SRv6 domain is separated by untrusted domain and SRv6 packets need to traverse it. This document describes some use cases of SRv6 across untrusted domain, and proposes a solution using IPSec technology. "MNA for Performance Measurement with Alternate Marking Method", Weiqiang Cheng, Xiao Min, Rakesh Gandhi, Greg Mirsky, Giuseppe Fioccola, 2025-03-02, MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. "Selective Synchronization for RPKI to Router Protocol", Nan Geng, Shunwan Zhuang, Yu Fu, Mingqing(Michael) Huang, 2025-04-14, The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronizations. The router can obtain only the data that it really needs, and it does not need to save the data that are not needed. "Scenarios and Challenges of Overlay Routing for SD-WAN", Cheng Sheng, Hang Shi, Linda Dunbar, Jie Dong, 2025-05-13, Overlay routing is essential during the enterprise networks' evolution from the interconnection among multiple on-premise branch sites to more advanced ones, such as the interconnection to multi- clouds. This document analyzes the technical requirements and challenges of overlay routing for SD-WAN in these scenarios. "Design analysis of methods for distributing the computing metric", Hang Shi, Cheng Li, Zongpeng Du, Xinxin Yi, Tianle Yang, 2025-05-15, This document analyses different methods for distributing the computing metrics from service instances to the ingress router. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Computing-Aware Traffic Steering Working Group mailing list (cats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cats/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-cats-method-analysis. "Structured Connection ID Carrying Metadata", Hang Shi, Mengyao Han, 2025-04-14, This document describes a mechanism to carry the metadata in the QUIC connection ID to communicate with the intermediary. "One Administrative Domain using BGP", Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen, 2025-02-24, 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). "Realization of Composite IETF Network Slices", Zhenbin Li, Jie Dong, Ran Pang, Yongqing Zhu, Luis Contreras, 2025-02-27, 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. "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance", Italo Busi, Jean-Francois Bouquier, Fabio Peruzzini, Paolo Volpato, Prasenjit Manna, 2025-02-26, This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. "The MASQUE Proxy", David Schinazi, 2025-02-18, MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. "Aircraft to Anything AdHoc Broadcasts and Session", Robert Moskowitz, Stuart Card, Andrei Gurtov, 2025-04-22, 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. "Efficient Air-Ground Communications", Robert Moskowitz, Stuart Card, Andrei Gurtov, 2025-03-18, This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery. "Green Challenges in Computing-Aware Traffic Steering (CATS)", Jing Wang, Yuexia Fu, Cheng Li, 2025-03-03, 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. "OSPF Adjacency Suppression", Weiqiang Cheng, Liyan Gong, Changwang Lin, Mengxiao Chen, 2025-02-15, This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. "Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS", Gilles Lehmann, 2025-04-01, The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. "BFD Path Consistency over SR", Changwang Lin, Weiqiang Cheng, Jiang Wenying, Ran Chen, 2025-01-14, Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy "Network-based mobility management in CATS network environment", Jaehwoon Lee, 2025-05-21, Computing-Aware Traffic Steering (CATS) network architecture is to choose the best edge computing server by considering both the network environment and available computing/storage resources of the edge computing server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress CATS-Router by using the PMIPv6-based mobility management method in the CATS-based edge computing networking environment. "RFC Style Guide", Sandy Ginoza, Jean Mahoney, Alice Russo, 2025-01-24, This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide". Note: This draft is being developed and discussed in the GitHub repo , but any substantive change should be discussed on . "Purge Originator Identification for OSPF", Zhenqiang Li, Changwang Lin, 2025-01-14, In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. "Galois Counter Mode with Strong Secure Tags (GCM-SST)", Matt Campagna, Alexander Maximov, John Mattsson, 2025-02-19, This document defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm. GCM-SST can be used with any keystream generator, not just 128-bit block ciphers. The main differences from GCM are the use of an additional subkey H_2, the derivation of fresh subkeys H and H_2 for each nonce, and the replacement of the GHASH function with the POLYVAL function from AES-GCM-SIV. This enables truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, which are significant security improvements over GCM. GCM-SST is designed for security protocols with replay protection and addresses the strong industry demand for fast encryption with minimal overhead and high security. This document registers several instances of GCM-SST using Advanced Encryption Standard (AES) and Rijndael-256. "Enforcing end-to-end delay bounds via queue resizing", Antoine Fressancourt, 2025-04-20, This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. "IGP Extensions for Deterministic Traffic Engineering", Shaofu Peng, 2024-12-23, This document describes IGP extensions to support Traffic Engineering (TE) of deterministic routing, by specifying new information that a router can place in the advertisement of neighbors. This information describes additional details regarding the state of the network that are useful for deterministic traffic engineering path computations. "A SAVI Solution for WLAN", Mingwei Xu, Jianping Wu, Tao Lin, Lin He, You Wang, 2025-05-28, This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. "A Mechanism for Encoding Differences in Paired Certificates", Corey Bonnell, John Gray, D. Hook, Tomofumi Okubo, Mike Ounsworth, 2025-04-16, 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. "Signaling In-Network Computing operations (SINC)", David Lou, Luigi Iannone, Yizhou Li, Zhangcuimin, Kehan Yao, 2025-05-19, This memo introduces "Signaling In-Network Computing operations" (SINC), a mechanism to enable signaling in-network computing operations on data packets in specific scenarios like NetReduce, NetDistributedLock, NetSequencer, etc. In particular, this solution allows to flexibly communicate computational parameters, to be used in conjunction with the payload, to in-network SINC-enabled devices in order to perform computing operations. "An Overview of Network Slicing Efforts in The IETF", Mohamed Boucadair, 2025-02-09, This document lists a set of slicing-related specifications that are being development within the IETF. This document is meant to provide an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent. "SRv6 Context Indicator SIDs for SR-Aware Services", Jiaming Ye, Changwang Lin, Dongjie Lu, Meiling Chen, 2025-03-02, A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. "WBA OpenRoaming Wireless Federation", Bruno Tomas, Mark Grayson, Necati Canpolat, Betty Cockrell, Sri Gundavelli, 2025-04-15, This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. "RIFT extensions for SRv6", Weiqiang Cheng, Changwang Lin, Ruixue Wang, 2025-03-03, The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the RIFT extensions required to support Segment Routing over the IPv6 data plane (SRv6). "Intel Profile for Remote Attestation", James Beaney, Yogesh Deshpande, Andrew Draper, Vincent Scarlata, Ned Smith, 2025-05-22, This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes apticulareplication of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers. "Latency Guarantee with Stateless Fair Queuing", Jinoo Joung, Jeong-dong Ryoo, Taesik Cheung, Yizhou Li, Peng Liu, 2024-12-25, This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding delay factors, which are functions of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. "SCION Control Plane", Corine de Kater, Nicola Rustignoli, Samuel Hitz, 2025-03-03, 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", Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes, 2025-03-03, 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. "Inter-domain Source Address Validation based on AS relationships", Ren Gang, Shuqi Liu, Xia Yin, 2025-03-02, This draft introduces a distributed inter-domain source address validation scheme based on AS relationships. It mainly describes this method from five aspects: the research background in related fields, introduction to the AS relationship classification and acquisition methods, the SAV system's architecture, typical use cases, and considerations on deployability. "HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman, 2025-01-06, Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. "Inband Telemetry for HPCC++", Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman, 2025-01-06, Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. "Routing mechanism in Dragonfly Networks Gap Analysis, Problem Statement, and Requirements", Ruixue Wang, Changwang Lin, wangwenxuan, Weiqiang Cheng, 2025-03-02, This document provides the gap analysis of existing routing mechanism in dragonfly networks, describes the fundamental problems, and defines the requirements for technical improvements. "Ping Path Consistency over SRv6", Liyan Gong, Changwang Lin, Yuanxiang Qiu, Xiao Min, 2025-01-22, In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. "Multiple Algorithm Rules in DNSSEC", Shumon Huque, Peter Thomassen, Viktor Dukhovni, Duane Wessels, Christian Elmerot, 2025-05-28, 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, 6840, and 8624. "Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism", Rafael Belchior, Miguel Correia, Andre Augusto, Thomas Hardjono, 2025-01-20, This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). "Separate Transports for IKE and ESP", Valery Smyslov, Tirumaleswar Reddy.K, 2025-04-15, 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. "Validity of SR Policy Candidate Path", Ran Chen, Yisong Liu, Ketan Talaulikar, Detao Zhao, Zafar Ali, 2025-01-25, 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. "Validity of SR Policy Candidate Path", Ran Chen, Detao Zhao, Ketan Talaulikar, Yisong Liu, Changwang Lin, 2025-06-04, This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy. "YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET)", Dan Li, Libin Liu, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng, 2025-03-27, 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. "Views and View Addresses for Secure Asset Transfer", Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Krishnasuri Narayanam, 2025-01-22, With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to-end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. "Protocol for Requesting and Sharing Views across Networks", Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy, 2025-01-22, With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. "Agreements To Fix Forwarding", Alessandro Vesely, 2025-05-01, The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. "An SR-TE based Solution For Computing-Aware Traffic Steering", FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, 2025-02-25, Computing-aware traffic steering (CATS) is a traffic engineering approach [I-D.ietf-teas-rfc3272bis] that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. Various relevant metrics may be used to enforce such computing-aware traffic steering policies.It is critical to meet different types of computing-aware traffic steering requirements without disrupting the existing network architecture. In this context, this document proposes a computing-aware traffic steering solution based on the SR- TE infrastructure of the current traffic engineering technology to reduce device resource consumption and investment and meet the requirements for computing-aware traffic steering of network devices. "Applying COSE Signatures for YANG Data Provenance", Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz, Sofia Garcia, 2025-04-23, 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. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. "BGP Attribute Escape", Jeffrey Haas, 2025-04-09, BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact. "Data Generation and Optimization for Network Digital Twin Performance Modeling", Mei Li, Cheng Zhou, Danyang Chen, 2025-03-02, Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network performance in various what-if scenarios. Recently, AI models, especially neural networks, have been applied for NDT performance modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model from the data perspective. "BGP SR Policy Extensions for Path Scheduling", Li Zhang, Tianran Zhou, Jie Dong, Minxue Wang, Nkosinathi Nzima, 2025-03-03, 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 BGP SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes. "IGP Prefix Independent Convergence", Yue Wang, Changwang Lin, Aijun Wang, 2025-02-15, In many cases, a large number of routes can be reached by multiple next hops. When a link fails, route calculation needs to be performed and a new reachable path needs to be calculated. If all routes are re-calculated and refreshed, the calculation time increases linearly as the number of routes increases, resulting in a long time for route convergence. This document describes an architecture where the number of prefixes is independent. This architecture allows routes to be recalculated when paths change, regardless of the number of IGP routes. "Advertisement of Candidate Path Validity Control Parameters using BGP-LS", Ran Chen, Detao Zhao, Ketan Talaulikar, Yisong Liu, Changwang Lin, 2025-06-05, This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc. "Usage of BGP-LS-SPF in Multi-segment SD-WAN", Cheng Sheng, Hang Shi, Jie Dong, 2025-05-17, This document introduces the usage of BGP-LS-SPF protocol in multi- segment SD-WAN scenarios. It allows SD-WAN tunnels to be published as logical links, which can cross the internet, MPLS networks, and various operator network. The BGP-LS-SPF protocol can construct an overlay network topology for logical links and physical links across these heterogeneous networks, and calculate the reachability routes of overlay network nodes based on this topology. "SAVI in an EVPN network", Eric Levy-Abegnoli, Pascal Thubert, Ratko Kovacina, 2025-01-20, Source Address Validation procedures have been specified in the SAVI Working Group and provide a set of mechanisms and state machines to verify Source Address ownership. The main mechanisms are described in RFC6620 and RFC7513. RFC7432 and furthermore RFC9161 specify how an EVPN network could learn and distribute IP addressess. RFC9161 describes a mechanism by which the PE can proxy some ND messages based on this information. In this document, we review how these two sets of specifications and underlying mechanisms can interact to provide Source Address Validation in an EVPN network. "Advertise NRP Group extensions for IGP", Weiqiang Cheng, Changwang Lin, Liyan Gong, 2025-01-05, Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes,structures, and functions so that each slice can be dedicated to specific services or customers. A Network Resource Partition (NRP) is a collection of resources in the underlay network. Each NRP is used as the underlay network construct to support one or a group of IETF network slice services. This document describes an IGP mechanism that is used to advertise a large number of NRPs into a smaller number of NRP groups. "The Secondary Label and its applications", MOHANTY Satya, Israel Means, Praveen Ramadenu, Mankamana Mishra, 2025-02-20, This draft utilizes the concept of a secondary label to solve few cases in L3VPN Deployments.In BGP VPN networks, BGP speakers associate a local MPLS label when the next-hop is reset and advertise that label to other peers. The receiving peer installs this "received" label in the forwarding and forwards traffic to the sending router using this label. In some deployments, there arises need where a different label is required to be sent. We illustrate with two use-cases. This draft presents a method where this label is encoded in a newly defined attribute that is advertised with the BGP updates targeting these specified use-cases "PCEP extension to support Candidate Paths validity", Ran Chen, Detao Zhao, Samuel Sidor, Mike Koldychev, Zafar Ali, 2025-06-05, This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy. "Computing-Aware Traffic Steering (CATS) Using Segment Routing", Cheng Li, Zongpeng Du, John Drake, 2025-01-28, 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 identifier and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. "Merkle Tree Ladder (MTL) Mode Signatures", Joe Harvey, Burt Kaliski, Andrew Fregly, Swapneel Sheth, 2025-03-15, 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 the Stateless Hash-Based Digital Signature Algorithm (SLH- DSA) specified in the draft FIPS 205. 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. "Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP)", Michael Tuexen, Hannes Tschofenig, Tirumaleswar Reddy.K, 2025-04-21, This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 6083. DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions. "MIMI Portability", Konrad Kohbrok, Raphael Robert, 2025-01-09, This document describes MIMI Portability mechanisms. "MIMI Attachments", Raphael Robert, Konrad Kohbrok, 2025-01-09, This document describes MIMI Attachments. "Crowd Sourced Remote ID", Robert Moskowitz, Adam Wiethuechter, 2025-03-03, This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. "eXtensible Stateless Equipment Data Exchange", Mark Spencer, Edward Guy,, Nick Hartley, 2025-06-16, This document presents a binary IP-based protocol to facilitate interoperable communications between electronic equipment on a platform. The protocol is UDP-based, stateless, and multicast. Messages consist of a common header followed by a series of parameters and related attributes. The parameters are always informational, e.g., indicating airspeed is 150 kts, but parameter attributes can be set to indicate intent, e.g., this parameter contains a new user selected value such as an instruction that deploys the landing gear. Although initially designed for avionics, it can be applied to other platform domains as well. This document defines the core protocol and a method to extend it to meet any domain specific needs. "Packed CBOR: Table set up by reference", Christian Amsuess, 2025-03-03, Packed CBOR is a mechanism for transforming Concise Binary Object Representation (CBOR) data into a more compact form. This document introduces a means for setting up its tables by means of dereferenceable identifiers, and introduces a pattern of using it without sending long identifiers. "The Restatement Anti-Pattern", Carsten Bormann, 2025-03-01, Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. "CBOR: On Deterministic Encoding and Representation", Carsten Bormann, 2025-01-21, CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides additional information about use cases, deployment considerations, and implementation choices for Deterministic Encoding and Representation. "Associated Gateway Exchange in Multi-segment SD-WAN", Cheng Sheng, Hang Shi, Jie Dong, Linda Dunbar, Gyan Mishra, 2025-05-17, The document describes the control plane enhancement for multi- segment SD-WAN to exchange the associated GW information between edges. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (idr@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/idr/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-sheng-idr-gw-exchange-in-sd-wan. "Hybrid IANA Registration Policy", John Klensin, 2025-04-14, 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. "Revocation in OpenPGP", Daniel Gillmor, Andrew Gallagher, 2025-03-28, Cryptographic revocation is a hard problem. OpenPGP's revocation mechanisms are imperfect, not fully understood, and not as widely implemented as they could be. Additionally, some historical OpenPGP revocation mechanisms simply do not work in certain contexts. This document provides clarifying guidance on how OpenPGP revocation works, documents outstanding problems, and introduces a new mechanism for delegated revocations that improves on previous mechanism. "KEM-based pre-shared-key handshakes for TLS 1.3", Thom Wiggers, Sofia Celi, Peter Schwabe, Douglas Stebila, Nick Sullivan, 2025-04-22, This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. "SW103K PROTOCOL", Chazah Group, 2025-05-29, The SW103k protocol addresses challenges in networks with limited bandwidth, latency constraints, and data integrity concerns. It provides compression and decompression to optimize bandwidth utilization in environments such as IoT, satellite, and mobile communications. The protocol operates at the data link layer with a custom frame format including SW103K and HAVI headers. Key features include: - Batch processing of 103 packets with compression - Merkle tree- based integrity verification (merklesw103k root hash) - QoS mechanisms with 8-bit priority field - Security features including AES-256-GCM encryption - Physical layer synchronization with +-1us accuracy Implementations include Linux kernel modules, FPGA encoders, and userspace daemons. The protocol supports interoperability with industrial standards like PROFINET and EtherCAT through custom mappings. "Terminal-based joint selection and configuration of MEC host and DETNET-RAW network", Carlos Bernardos, Alain Mourad, 2025-05-21, There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. "Extensions to enable wireless reliability and availability in multi-access edge deployments", Carlos Bernardos, Alain Mourad, 2025-05-21, There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. "MIPv6 DETNET-RAW mobility", Carlos Bernardos, Alain Mourad, 2025-05-21, There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. "DetNet multidomain extensions", Carlos Bernardos, Alain Mourad, 2025-02-26, 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. "4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks", Guozhen Dong, Chongfeng Xie, Xing Li, Shuping Peng, 2025-04-21, This document defines a new type of segment for Segment Routing, 4map6 segment, which is an IPv4/IPv6 conversion function based on stateless mapping rules running in PE nodes for the delivery of IPv4 services over IPv6-only network. At the same time, the BGP Prefix- SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. "Email Feedback Reports for DKIM Signers", Alex Brotman, 2025-03-03, 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. "Constraining RPKI Trust Anchors", Job Snijders, Theo Buehler, 2025-05-05, This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. 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. "Research Agenda for a Post-Quantum DNSSEC", Andrew Fregly, Roland van Rijswijk-Deij, Moritz Mueller, Peter Thomassen, Caspar Schutijser, Taejoong Chung, 2024-12-23, This document describes a notional research agenda for collaborative multi-stakeholder research related to a future post-quantum DNSSEC ecosystem. It is inspired by the anticipation that adoption of Post- Quantum signature algorithms will have enough operational impact on DNSSEC that either DNS protocol enhancements will be needed, or DNS will move away from UDP as the prevalent DNS transport, or a combination of both will be needed. Some members of the DNS technical community have even suggested evaluating alternatives to DNSSEC and potentially adopting an alternative protocol or practices to assure the integrity of DNS responses. Given the potential impact of such changes on the DNS ecosystem, the authors believe collaborative multi-stakeholder research into the impact of proposed changes should be performed to inform adoption and standardization activities. "Resource Guarantee for SRv6 Policies", Weiqiang Cheng, Jiang Wenying, Ran Chen, Changwang Lin, Geng Zhang, 2025-04-30, This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list, the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. "SCION Data Plane", Corine de Kater, Nicola Rustignoli, Jean-Christophe Hugly, Samuel Hitz, 2025-03-03, 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. "Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification", Daniel Migault, Joel Halpern, Stere Preda, Daiying Liu, U. Parkholm, 2025-03-30, 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. "OpenPGP HTTP Keyserver Protocol", Daphne Shaw, Andrew Gallagher, 2025-03-18, This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. "PCEP Extensions to Support Signaling Candidate Path Threshold Constraints of SR Policy", Yisong Liu, Changwang Lin, Shuping Peng, Yuanxiang Qiu, 2025-02-15, This document defines the extensions of PCEP to signal the threshold and metric constraint parameters of candidate paths for SR Policy to support flexible path selection. "The Mastic VDAF", Hannah Davis, Dimitris Mouris, Christopher Patton, Nektarios Tsoutsos, 2025-01-23, This document describes Mastic, a two-party VDAF for the following secure aggregation task: each client holds an input string and an associated weight, and the data collector wants to aggregate the weights of all clients whose inputs begin with a prefix chosen by the data collector. This functionality enables two classes of applications. First, it allows grouping metrics by client attributes without revealing which clients have which attributes. Second, it solves the weighted heavy hitters problem, where the goal is to compute the subset of inputs that have the highest total weight. "Classic McEliece", Simon Josefsson, 2025-03-17, This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. 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-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. "IGP Flexible Algorithm with Link Loss", Wang Yifan, Guoqi Xu, Xuesong Geng, Jie Dong, Peter Psenak, 2025-03-03, This document proposes extensions to the IGP Flexible Algorithms framework defined in [RFC9350]. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link loss measurements advertised via IS-IS [RFC8570] and OSPF [RFC7471], and defines new constraints for Flex-Algorithm path calculation. "CDNI Metadata Expression Language", Will Power, Glenn Goldstein, Arnon Warshavsky, 2025-02-25, This document specifies the syntax and provides usage examples for an expression language to be used within Streaming Video Technology Alliance (SVTA)/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", Glenn Goldstein, Will Power, Arnon Warshavsky, 2025-02-25, 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. "BGP Flow Specification for Source Address Validation", Nan Geng, Dan Li, tongtian124, Mingqing(Michael) Huang, 2025-04-14, 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. "A YANG Data Model for Microwave Radio Link", Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala, 2025-04-04, 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. "Recommendations for using Multiple IP Addresses in Benchmarking Tests", Gabor Lencse, Keiichi Shima, 2025-04-18, RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. "Reliability in AI Networks Gap Analysis, Problem Statement, and Requirements", Weiqiang Cheng, Changwang Lin, wangwenxuan, Bohua Xu, 2025-06-06, This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. "IGP Color-Aware Routing", Changwang Lin, Mengxiao Chen, Liyan Gong, 2025-06-06, This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. "YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane", Yisong Liu, Changwang Lin, Xufeng Liu, 2025-06-06, This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. "A Multiplane Architecture Proposal for the Quantum Internet", Diego Lopez, Vicente Martin, Blanca Lopez, Luis Contreras, 2025-02-26, 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. "Philatelist, YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases", Jan Lindblad, 2025-02-28, Timestamped telemetry data is collected en masse today. Mature tools are typically used, but the data is often collected in an ad hoc manner. While the dashboard graphs look great, the resulting data is often of questionable quality, not well defined, and hard to compare with seemingly similar data from other organizations. This document proposes a standard, extensible, cross domain framework for collecting and aggregating timestamped telemetry data in a way that combines YANG, metadata and Time Series Databases to produce more transparent, dependable and comparable results. This framework is implemented in the Network Controller layer, but is rooted in data that is collected from all kinds of Network Elements and related systems. "Semantic Definition Format (SDF) modeling for Digital Twin", Hyunjeong Lee, Jungha Hong, Joo-Sang Youn, Yong-Geun Hong, 2025-06-14, 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. "Advertising SaaS Path Performance Metrics using BGP", Cheng Sheng, Hang Shi, Jie Dong, Linda Dunbar, 2025-05-17, This document extends BGP to advertise the SaaS path performance metrics from the gateway sites to branch sites. The user can access SaaS applications through the DIA (Direct Internet Access) link at the branch site or through the DIA link at the gateway site, or use the DIA link of a gateway site for redundancy. This approach will improve the SaaS access experience for end-users. "SRH Reduction for SRv6 End.M.GTP6.E Behavior", Yuya Kawakami, Satoru Matsushima, Shay Zadok, Derek Yeung, Dan Voyer, 2025-03-02, Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. "Enhanced Use Cases for Scaling Deterministic Networks", Junfeng Zhao, Quan Xiong, Zongpeng Du, Muhammad Jadoon, Luis Contreras, 2025-03-03, This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video, intelligent computing, and ISAC-enabled smart factory and outlines the common properties implied by these use cases. "Proposed Update to BGP Link-State SPF NLRI Selection Rules", Jie Dong, chenjinqiang, Sheng Fang, 2025-03-03, 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, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. "Automating DNS Delegation Management via DDNS", Johan Stenstam, Erik Bergstrom, Leon Fernandez, 2025-03-03, 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. "TLS Flag - Request mTLS", Jonathan Hoyland, 2025-02-28, Normally in TLS there is no way for the client to signal to the server that it has been configured with a certificate suitable for mTLS. This document defines a TLS Flag [I-D.ietf-tls-tlsflags] that enables clients to provide this hint. "BIER Loop Avoidance using Segment Routing", Yisong Liu, Changwang Lin, Zheng Zhang, Yuanxiang Qiu, 2025-02-15, This document provides a mechanism leveraging SR-MPLS/SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. "IKEv2 support for specifying a Delete notify reason", Antony Antony, Patrick Kerpan, Paul Wouters, 2025-03-03, This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). "Adaptive Routing Notification", Haibo Wang, Hongyi Huang, Xuesong Geng, Xiaohu Xu, Yinben Xia, 2025-03-31, Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and/or improve transport reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, is growing popular in commodity data centers to dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, the sensing node can not only apply AR locally but also send the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the reported path. This document specifies Adaptive Routing Notification (ARN), a general mechanism to proactively disseminate congestion detection and congestion elimination information for remote nodes to perform re-routing policies. Particularly for AI workloads like DeepSeek's MoE models that exhibit dynamic all-to-all communication patterns with bursty traffic characteristics, such mechanisms become crucial to enable immediate network response to transient congestion conflicts. "Post-Quantum Cryptography Recommendations for TLS-based Applications", Tirumaleswar Reddy.K, Hannes Tschofenig, 2025-02-25, Post-quantum cryptography presents new challenges for applications, end users, and system administrators. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and key supporting protocols such as DNS. "Application of Explicit Measurement Techniques for QUIC Troubleshooting", Alexandre Ferrieux, Igor Lubashev, Giuseppe Fioccola, Lars Ihlar, Fabio Bulgarella, Mauro Cociglio, Isabelle Hamchaoui, Massimo Nilo, 2025-02-28, This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). "RTP Payload Format for Geometry-based Point Cloud Compression", Mathis Engelbart, Joerg Ott, Lukasz Kondrad, 2025-03-03, This memo describes an RTP payload format for geometry-based point cloud compression (G-PCC) ([ISO.IEC.23090-9]). The RTP payload format defined in this document supports the packetization of one or more data units in an RTP packet payload and the fragmentation of a single data unit into multiple RTP packets. This memo also describes congestion control for a practical solution for the real-time streaming of point clouds. Finally, the document defines parameters that may be used to select optional features of the payload format or signal properties of the RTP stream. The parameters can be used with the Session Description Protocol (SDP). "Path Computation Based on Precision Availability Metrics", Luis Contreras, Fernando Agraz, Salvatore Spadaro, Quan Xiong, 2025-03-03, 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. "Aggregation Trace Option for In-situ Operations, Administration, and Maintenance (IOAM)", Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger, 2025-04-23, The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. "Trust and security considerations for Structured Email", Hans-Joerg Happel, Arnt Gulbrandsen, 2025-05-13, 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. "Kademlia-directed ID-based Routing Architecture (KIRA)", Roland Bless, 2025-03-02, 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. "Centralized Anycast Gateway in Ethernet VPN(EVPN)", Neeraj Malhotra, Krishnaswamy Ananthamurthy, Ali Sajassi, Lukas Krattiger, Jorge Rabadan, 2025-03-18, EVPN Integrated Routing and Bridging (IRB) fabrics provide a flexible and extensible method for Layer-2 and Layer-3 overlay network connectivity. [EVPN-IRB] defines operation for symmetric and asymmetric EVPN IRB using distributed anycast gateway architecture (DAG). In a DAG architecture, both bridging and first-hop routing functions for overlay subnets are located on leaf PEs, with first-hop routing provided by a distributed anycast gateway provisioned across the leaf PEs. This document describes an architecture and operation for EVPN Centralized Anycast Gateway (CAG), which allows the first- hop routing function for overlay subnets to be centralized on designated IRB GWs while the bridging function is still located on the leaf PEs. The documents also covers trade-offs of deploying a CAG as compared with DAG. It further describes operation for inter- op between CAG and DAG based EVPN-IRB network overlays. "Current Process for Handling RFC Errata Reports", Alice Russo, Jean Mahoney, 2025-03-02, This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. "Usage specification of the otpauth URI format for TOTP and HOTP token generators", Ilteris Eroglu, 2025-02-17, This document describes a foundational schema for the otpauth URI, utilized by TOTP (and/or HOTP) based authenticators. "SCIM Delta Query", Anjali Sehgal, Danny Zollner, 2025-01-09, This document defines extensions to the SCIM 2.0 protocol that enable clients to poll service providers for changes that have occurred since a delta (or watermark) token was issued by the service provider. "Identity Trust System", Luigi Sbriz, 2025-05-09, This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: "RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling", Mohamed Boucadair, Luis Contreras, Oscar de Dios, Thomas Graf, Reshad Rahman, Lionel Tailhardat, 2025-05-12, 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. "Fully Adaptive Routing Ethernet using LSR", Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, 2025-05-21, Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination over multiple equal-cost paths, based on network capacity and even congestion information along those paths. "Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk", Magnus Westerlund, John Mattsson, Claudio Porfiri, 2025-03-03, This document defines a usage of Datagram Transport Layer Security (DTLS) 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP DTLS chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re- authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). "Stream Control Transmission Protocol (SCTP) DTLS Chunk", Magnus Westerlund, John Mattsson, Claudio Porfiri, 2025-03-03, 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. "LibrePGP Message Format", Werner Koch, Ronald Tse, 2025-03-17, This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). "Path Tracing in SRv6 networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija, 2025-05-18, Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. "PKCS #15 Updates", Peter Gutmann, 2025-02-17, This document describes updates to the PKCS #15 standard made since the original publication of the standard. "AEGIS-based Cipher Suites for TLS 1.3, DTLS 1.3 and QUIC", Frank Denis, Samuel Lucas, 2025-05-25, This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. 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-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. "Payload Protocol Identifier based Fragmentation and Reassembly for the Stream Control Transmission Protocol", Michael Tuexen, Randell Jesup, Hannes Tschofenig, 2025-03-02, This document describes a method for the Stream Control Transmission Protocol (SCTP) allowing the upper layer to perform fragmentation, reassembly, and interleaving of large ordered user messages by using the payload protocol identifier (PPID). According to the base specification supporting fragmentation of large user messages is optional. And even if an SCTP implementation supports fragmentation, interleaving of user messages is not supported by the base specification. "Paired MLS - PCS in Limited Modes", Elsie Fondevik, Britta Hale, Xisen Tian, 2025-06-12, This document describes the Paired Messaging Layer Security (MLS) extension that improves Post Compromise Security for devices that are unable to self-update using a trusted paired device. "MLS Virtual Clients", Joel, Konrad Kohbrok, Raphael Robert, 2025-01-09, 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. "Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC", Andrew Fregly, Joe Harvey, Burt Kaliski, Duane Wessels, 2025-04-02, This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval. "CoAP in Space", Carles Gomez, Sergio Aguilar, 2024-12-30, This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. "Outer Header Translator", Naoki Matsuhira, 2025-03-02, 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. "Secure Shell Key Exchange Method Using Chempat Hybrid of Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512", Simon Josefsson, 2025-03-18, 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. "RDAP Extension for DNS Time-To-Live (TTL Values)", Gavin Brown, 2024-12-16, This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. "WebTransport over WebSocket", Marten Richter, 2025-05-24, WebTransport [OVERVIEW], a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket [WEBSOCKET], offering WebTransport capabilities similar to the HTTP/2 variant [WEBTRANSPORT-H2]. It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket [WEBSOCKET]. "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs)", Hannes Tschofenig, Brendan Moran, Henk Birkholz, 2025-03-02, 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", Yisong Liu, Changwang Lin, Mukul Srivastava, 2025-01-06, This document proposes an aggregated BMP route monitoring message. 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 network overhead. This document updates RFC 7854 by adding new BMP Messages type. "Intra-domain SAVNET Support via IGP", Weiqiang Cheng, Dan Li, Changwang Lin, 1211176911910469110103, Xueyan Song, 2025-03-02, This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. "X-Wing: general-purpose hybrid post-quantum KEM", Deirdre Connolly, Peter Schwabe, Bas Westerbaan, 2025-05-03, This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. "Bicone Source Address Validation", Lancheng Qin, Dan Li, Li Chen, Libin Liu, 2025-03-30, The primary design goal of source address validation (SAV) is avoiding improper blocks (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter based on BGP updates, ROAs, and ASPAs related to the provider cone. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. "Support of Observation Timestamp in YANG-Push Notifications", Thomas Graf, Benoit Claise, Alex Feng, 2024-12-14, This document extends YANG-Push Notifications with the YANG objects observation timestamp and point-in-time for streaming update YANG- Push notifications. "Paths Limit for Multiple Paths in BGP", Donatas Abraitis, Alvaro Retana, Jeffrey Haas, 2025-02-08, This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. "Safe(r) Limited Domains", Warren Kumari, Andrew Alston, Eric Vyncke, Suresh Krishnan, Donald Eastlake, 2025-03-03, Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks. "IPv4 routes with an IPv6 next hop", Juliusz Chroboczek, Warren Kumari, Toke Hoeiland-Joergensen, 2025-01-20, This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. "The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model", Ziyang Xing, Xiaoqiang Di, Hui Qi, 2025-06-09, This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) or Link Layer Discovery Protocol (LLDP) in Software-Defined Networking (SDN). In a traditional Software-Defined Networking, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. "Asset Schema Architecture for Asset Exchange", Denis Avrilionis, Thomas Hardjono, 2025-02-17, A management architecture for asset schemas and profiles is needed to enable entities in the tokenized assets ecosystem to instantiate tokens within one or more asset networks. An asset network may be constrained to support only a select class or type of token to be present in the network. In the SATP protocol, the receiving gateway at the destination network is assumed in its preparatory stages to evaluate the transfer request of a tokenized asset from the sending gateway at the origin network. In order to evaluate the proposed transfer, the receiving gateway must have access to the asset definition schema upon which the token was based in the origin network. The current document discusses the management architecture for the asset definition schema and the schema-profiles derived from the definition schema. "Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)", Yanfei Guo, Liang Xia, Yu Fu, 2025-02-27, This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on ISO and Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms is ISO standardization and are mandatory for some scenario in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. "IPv6 Address Assignment for SRv6", Yisong Liu, Yongqing Zhu, 2025-02-25, This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios. "Security and Privacy Implications of 3GPP AI/ML Services for 6G", Behcet Sarikaya, Roland Schott, 2025-05-12, This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) services. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. "Something Better Than Errata", Stephen Farrell, 2024-12-18, This document outlines some ideas for a new errata handling policy that would (in the author's view) be better than current errata handling. This is for discussion and is not expected to become an RFC. "Characterization and Benchmarking Methodology for Power in Networking Devices", Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, 2025-01-30, This document defines a standard mechanism to measure, report, and compare power usage of different networking devices and under different network configurations and conditions. "SIP Product Identifier", Roland Jesske, Bastian Dreyer, Michael Kreipl, Roland Schott, 2025-03-26, Complex telephony networks using SIP signalling such as the IP Multimedia Subsystem (IMS) of the Third Generation Partnership (3GPP) serve diverse customer groups, including business and retail clients, with various products like mobile, fixed, and PBX services. Such services have the problem of different handling of the services. This may end up in a complex analysis of the signalling syntax before starting the required procedures for calls based on their service provided to the customer. With the introduction of microservice based technologies the complexity increases. This draft describes a generic identification mechanism for SIP dialogs in using an identifier indicating the service/product which the customer is using to allow an efficient processing of the SIP dialog and session. "IPv4 Parcels and Advanced Jumbos (AJs)", Fred Templin, 2025-05-21, IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs for both existing Internetworking pathways and a new link model for the future. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. "IPv6 Parcels and Advanced Jumbos (AJs)", Fred Templin, 2025-05-21, IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of-packets", while AJs offer essential operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Networking (DTN) link model. "Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms", Simon Josefsson, 2025-03-18, 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. "Hash-based Signatures: State and Backup Management", Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis, 2025-04-01, Stateful Hash-Based Signature Schemes (S-HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large- scale quantum computers. Unlike conventional stateless digital signature schemes, S-HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered. "IPv6 Extended Fragment Header (EFH)", Fred Templin, Tom Herbert, 2025-06-03, The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification with efficient fragmentation and reassembly procedures. "IPv6 Extended Fragment Header for IPv4", Fred Templin, 2025-06-03, The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. "Stand-in Tags for YANG-CBOR", Carsten Bormann, Maria Matejka, 2025-03-03, YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. "Circuit Style Segment Routing Policies with Optimized SID List Depth", Amal Karboubi, Cengiz Alaettinoglu, Himanshu Shah, Siva Sivabalan, Todd Defillipi, 2025-02-21, Service providers require delivery of circuit-style transport services in a segment routing based IP network. This document introduces a solution that supports circuit style segment routing policies that allows usage of optimized SID lists (i.e. SID List that may contain non-contiguous node SIDs as instructions) and describes mechanisms that would allow such encoding to still honor all the requirements of the circuit style policies notably traffic engineering and bandwidth requirements. "A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET", Li Chen, Libin Liu, Dan Li, Lancheng Qin, 2025-03-18, This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter- domain SAV and is ready to establish neighbor relationship for preventing source address spoofing. "Enhancing Route Origin Validation by Aggregating Validated ROA Payloads", Jia Zhang, Mingwei Xu, Yangyang Wang, 2025-02-27, Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. "Terminal Identity Authentication Based on Address Label", Jianfeng Guan, Su Yao, Kexian Liu, Xiaolong Hu, Jianli Liu, 2025-01-18, This document proposes an IPv6-based address label terminal identity authentication architecture, which tightly binds identity information to the source address of data packets. This approach enables hop-by- hop identity authentication while ensuring source address verification. The mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document details the implementation of address label authentication within the IPv6 extension header. "IP Payload Compression excluding transport layer", Cheng Li, Hang Shi, Meng Zhang, Xiaobo Ding, 2025-04-15, IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. "On-time Forwarding with Push-In First-Out (PIFO) queue", Yeoncheol Ryoo, 2025-02-26, 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. "ACLs within the NFSv4 Protocols", David Noveck, 2025-05-24, This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis respecification effort for NFSv4.1. It describes the structure and function of NFsv4 Access Control Lists within all existing minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. [Consensus Needed (Item #117a)]: Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was originally intended, this document clarifies the status of draft-POSIX ACLs, with the expectation that support for these might be provided via a later extension. In addition, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. [Consensus Needed (Item #117a)]: In this document, the relationship among the multiple ACL models for which support was intended has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now- withdrawn draft-POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft-POSIX ACL model are considered as OPTIONAL extensions to that core, with the latter not yet present in NFsv4.1. [RFC Editor: please remove this parapgraph and the following paragraph prior to publishing this document as an RFC]. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts provide a framework for addressing these issues and obtaining working group consensus regarding changes that will be necesasary before publication of RFCTBD10. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. "Latency analysis of mobile transmission", Balazs Varga, Joachim Sachs, Frank Duerr, Samie Mostafavi, 2025-03-27, Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. "Computing Aware Traffic Steering using IP address anchoring", Carlos Bernardos, Alain Mourad, 2025-02-26, 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 for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. "Customer Experience Index for Evaluating Network Quality for Cloud Applications", Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Xuesong Geng, Hongyi Huang, Tianran Zhou, Jian Ge, KE Ma, Ruihao Chen, 2025-04-20, This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network. "Flow Aggregation for Enhanced DetNet", Quan Xiong, Tianji Jiang, Jinoo Joung, 2025-02-25, This document describes the objectives and requirements of flow aggregation in scaling networks. It proposes a scheme by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet, and suggests the flow identification of aggregated-class be used to indicate the required treatment and forwarding behaviors in scaling networks. Toward the end, the draft discuss how the novel flow aggregation scheme could be applied to realize the flow aggregation in a 5GS logical DetNet node participating in enhanced DetNet. "SRv6 Service SID Anycast Flag", Yisong Liu, Changwang Lin, Yao Liu, 2025-03-18, 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 the Anycast-flag for SRv6 Service SIDs carried in BGP messages. "Constrained Application Protocol (CoAP) over Bundle Protocol (BP)", Carles Gomez, Anna Calveras, 2025-01-19, 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. "Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring", Carlos Bernardos, Alain Mourad, 2025-03-03, 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 connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. "Advanced Professional Video", Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi, 2025-04-15, This document describes bitstream format of Advanced Professional Video and decoding process of it. "The Asynchronous Remote Key Generation (ARKG) algorithm", Emil Lundberg, John Bradley, 2025-04-29, Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. "Identity Assertion Authorization Grant", Aaron Parecki, Karl McGuinness, 2025-04-22, This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. "IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method", Xiaoming He, Xiao Min, Frank Brockners, Giuseppe Fioccola, Chongfeng Xie, 2025-02-26, In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. "IKEv2 support for Child SA PFS policy notification", Paul Wouters, 2025-03-03, This document defines the CHILD_PFS_INFO Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support exchanging the policy settings for the Perfect Forward Secrecy (PFS) and which Key Exchange (KE) method(s) setting of the initial Child SA that are expected to be used during Child SA rekey. "Data Fields for Congestion Measurement", Hang Shi, Tianran Zhou, Guangyu Zhao, Zhenqiang Li, 2025-04-14, Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement command in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, aids in effective load balancing, and simplifies network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. "IPv6 Options for Congestion Measurement", Hang Shi, Tianran Zhou, liuy619@chinaunicom.cn, Mengyao Han, 2025-03-03, The Congestion Measurement enables precise congestion control, aids in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document outlines how Congestion Measurement Data-Fields are encapsulated in IPv6. "Discovery of Network-designated OSCORE-based Resolvers: Problem Statement", Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch, 2025-03-03, This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. "Operations, Administration and Maintenance (OAM) for Computing-Aware Traffic Steering", FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan, 2025-02-25, This document describes an OAM framework for Computing-Aware Traffic Steering (CATS). The proposed OAM framework enables the fault and the performance management of end-to-end connections from clients to networks and finally to computing instances. In the following sections, the major components of the framework, the functionalities, and the deployment considerations are elaborated in detail. "Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering", FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan, 2025-02-25, This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios. "Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture", Tran Ngoc, Younghan Kim, 2025-02-28, The document [I-D.draft-mhkk-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. "SAVNET Use Cases", 1211176911910469110103, Xueyan Song, Changwang Lin, Nan Geng, 2025-03-03, This document introduces the use case for Source Address Validation (SAV) applied in intra-domain and inter-domain telecommunication networks. It describes the typical routing implements and possible improvements for SAV in the use cases. "Intra-domain SAV Support via BGP", Weiqiang Cheng, Changwang Lin, 1211176911910469110103, 2024-12-29, This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes. "BGP Flowspec for Computing-Aware Traffic Steering", Changwang Lin, Huijuan Yao, Zhenqiang Li, 2025-03-16, Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes traffic steering to a given service instance by taking into account the dynamic nature of both computing and network resources. This document extends Version 2 of the BGP Flow Specification (BGP-FS) to enable flow classification and path selection for CATS flow categories, thus supporting the deployment of CATS traffic optimization. "Distribute Service Metric by BGP", Changwang Lin, Huijuan Yao, 2025-06-06, When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. "An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems", Jaehoon Jeong, Yiwen Shen, Yoseop Ahn, Mose Gu, 2025-06-09, Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. "Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP", Ruixue Wang, Changwang Lin, Mengxiao Chen, Fengwei Qin, Qi Zhang, wangwenxuan, 2025-03-18, This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. "CDNI Source Access Control Metadata", Pankaj Chaudhari, Glenn Goldstein, Will Power, Arnon Warshavsky, 2025-02-25, 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. "CDNI Delivery Metadata", Guillaume Bichot, Alfonso Siloniz, Glenn Goldstein, 2025-02-25, This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior for downstream CDN (dCDN) node selection, and request routing modes of traffic delegation. "CDNI Private Features Metadata", Arnon Warshavsky, Guillaume Bichot, Glenn Goldstein, 2025-02-25, This specification defines a mechanism for downstream content delivery networks (dCDNs) to define private extensions to the metadata model that are mutually agreed upon between participating upstream content delivery networks (uCDNs) and dCDNs. "Light MLS", Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk, 2025-03-03, The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state, which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "light clients" that don't undertake these costs. A light client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a light client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. "STI Certificate Transparency", Chris Wendt, Robert Sliwa, Alec Fenichel, Vinit Gaikwad, 2025-06-11, This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR eco-system, focusing on verifiable control over telephone number or service provider code resources. "Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson, Magnus Westerlund, Mirja Kuehlewind, 2025-03-03, 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. "Private Inexpensive Norm Enforcement (PINE) VDAF", Junye Chen, Christopher Patton, 2025-02-04, This document describes PINE, a Verifiable Distributed Aggregation Function (VDAF) for secure aggregation of high-dimensional, real- valued vectors with bounded L2-norm. PINE is intended to facilitate private and robust federated machine learning. "End-to-End Secure Objects for Media over QUIC Transport", Cullen Jennings, Suhas Nandakumar, Richard Barnes, 2025-02-28, 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. "EVPN Group Policy", Wen Lin, Dhananjaya Rao, Ali Sajassi, Larry Kreeger, Jorge Rabadan, 2025-06-05, Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. "SRv6 SFC Architecture with SR-aware Functions", Wataru Mishima, 59 61, 2025-01-31, This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, so that reduces nodes and address resource consumption. 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://https/github.com/watal. "Secure Group Key Agreement with MLS over MoQ", Cullen Jennings, Suhas Nandakumar, Richard Barnes, 2025-03-03, This specification defines a mechanism to use Message Layer Security (MLS) to provide end-to-end group key agreement for Media over QUIC (MOQ) applications. Almost all communications are done via the MOQ transport. MLS requires a small degree of synchronization, which is provided by a simple counter service. "PQ/T Hybrid KEM: HPKE with JOSE/COSE", Tirumaleswar Reddy.K, Hannes Tschofenig, 2025-02-16, This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. "Filtering Out RPKI Data by Type based on Enhanced SLURM Filters", Yu Fu, Nan Geng, 2025-01-01, Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. "SRv6 Deployment and Operation Problem Summary", Yisong Liu, Dan Voyer, Thomas Graf, Zoltan Miklos, Luis Contreras, Nicolai Leymann, Linjian Song, Satoru Matsushima, Chongfeng Xie, Xinxin Yi, 2025-05-08, This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. "Ways to convey the Ratchet Tree in Messaging Layer Security", Rohan Mahy, 2025-04-22, 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. "Common BMP Route-Monitoring Messages for Routes Unchanged by Policy", Dhananjay Patki, Narasimha Prasad, 2025-02-24, 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 methods to avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out. "High Assurance DIDs with DNS", Jesse Carter, Jacques Latour, Mathieu Glaude, Tim Bouma, 2025-05-05, This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. "Multiple Hop Unaffiliate BFD", Jiang Wenying, Changwang Lin, Xiao Min, 2025-03-27, 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. "GMA Traffic Splitting Control", Jing Zhu, Menglei Zhang, Sumit Roy, 2025-03-03, This document specifies the GMA (Generic Multi-Access) traffic splitting control algorithm. The receiving endpoint measures one- way-delay, round-trip time, and delivery rate for multiple connections and determines how a data flow is split across them. When update is needed, it will send out a control message, aka Traffic Splitting Update (TSU), to notify the transmitting endpoint of the new traffic splitting configuration. Compared to other sender-based multi-path transport protocols, e.g. MPTCP, MPQUIC, the GMA traffic splitting algorithm is receiver-based and does not require per-packet feedback, e.g. Ack. It is designed specifically to support the Generic Multi-Access (GMA) convergence protocol as introduced in [MAMS] [GMA]. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. "Registry policies "... with Expert Review"", Carsten Bormann, Marco Tiloca, 2025-04-08, 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 haven't been finalized, this document offers text that can be copy-pasted into specifications that want to make use of the augmented policies. "MIMI Metadata Minimalization (MIMIMI)", Konrad Kohbrok, Raphael Robert, 2025-04-07, This document describes a proposal to run the MIMI protocol in a way that reduces the ability of the Hub and service providers to associate messaging activity of clients with their respective identities. For now, this document only contains a high-level description of the mechanisms involved. "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, 2025-06-13, 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. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. "Automatic Extended Route Optimization (AERO)", Fred Templin, 2025-06-13, This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI uses 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. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. 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. "SRv6 Resource Programming with NRP flavor", Liyan Gong, Changwang Lin, 2025-06-06, This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. "Application-Responsive Network Framework", Feng Yang, Changwang Lin, 2025-03-03, With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. "RDAP Extension for DNS DELEG", Zaid AlBanna, Scott Hollenbeck, 2025-03-31, This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. "Double Nonce Derive Key AES-GCM (DNDK-GCM)", Shay Gueron, 2025-03-21, This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM). It operates with a 32- byte root key and is designed to encrypt with a 24-byte random nonce and optionally to provide for key commitment. Encryption takes the root key and a 15-byte portion of the random nonce, and derives a fresh 32-byte encryption key and (optionally) a key commitment value. Then, it invokes AES-GCM with the derived key and the remaining bytes of the nonce, and outputs the ciphertext, authentication tag and the key commitment value. Although this is not the primary use case, it is also possible to use DNDK-GCM with a non-repeating but non-random nonce (i.e., a "counter- based nonce"). The low collision probability in a collection of 24-byte random nonces and the per-nonce derivation of an encryption key extend the lifetime of the root key, and the scheme can support processing up to 2^64 bytes under a given root key. DNDK-GCM introduces a relatively small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption that AES acts as a pseudorandom permutation. "Security Considerations for Computing-Aware Traffic Steering", Cuicui Wang, Yu Fu, 2025-04-24, Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. "Representing metadata annotations in YANG-CBOR", Carsten Bormann, 2025-03-03, This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). "Fast Congestion Notification Packet (CNP) in RoCEv2 Networks", Xiao Min, lihesong, 2025-06-09, This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. "An Update on Milestones", David Schinazi, 2024-12-18, As mandated in RFC 2418, working group charters currently contain milestones. However, these milestones are often sufficiently out of date that they no longer provide value. This document makes milestones optional and allows more discretion on their dates. It updates RFC 2418. "Unmasked BIER Mode", Tony Przygienda, Zhaohui Zhang, Hooman Bigdoli, IJsbrand Wijnands, 2025-02-23, The document introduces a new mode of interpretation of the bitmask field in the BIER encoding, called unmasked BIER, that solves the problem of BIER originator targeting receivers across many different sets and hence, in worst case, degrading into ingress replication. "A Formalization of Symbolic Expressions", Marc Petit-Huguenin, 2025-05-04, The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. "Asset Profiles for Asset Exchange", Denis Avrilionis, Thomas Hardjono, 2025-02-17, A definition of asset schema and profiles is needed to provide a semantic definition of tokenized assets. The Asset schema is an abstract construct at the root hierarchy of more specific "asset profiles". Asset profiles describe the structure (type) of assets that are specific to a given domain or industry. An asset instance that is instantiated in a specific network and is exchanged via the SATP protocol has an instance-class relationship (in an ontological sense) with a given profile. Asset profiles are essential to the SATP protocol as they define the semantics of asset instances to be transferred. Gateways may negotiate asset transfers based on the nature and abilities of the assets as defined according to their profile. The current document discusses the definition of the asset schema and profile. "Problem statements and requirements of Deterministic CATS on the Industrial Internet", Tao Fu, Zhang Hengsheng, Jing Wang, 2025-03-03, This draft illustrates use cases of traffic steering for Industrial Internet in terms of dynamic computing and networking resource status,together with the requirements and solutions for CATS(Computing-Aware Traffic Steering).Industrial production tasks are time-sensitive, which put forward high requirements on collaboration of networks and applications. Industrial management platforms need to unify network forwarding and computing tasks at the same time. "Distributed Symmetric Key Establishment (DSKE)", Mattia Montagna, Manfred von Willich, Melchior Aelmans, Gert Grammel, 2025-03-17, This document defines a robust, scalable, and future-proofed security protocol for Symmetric Key Distribution without reliance on asymmetric encryption. This document delineates the protocol's specifications, security model, and architectural integration of the Distributed Symmetric Key Establishment (DSKE) protocol. Note This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. "SATP Setup Stage", Denis Avrilionis, Thomas Hardjono, 2025-02-17, SATP Core defines an unidirectional transfer of assets in three stages, namely the Transfer Initiation stage (Stage-1), the Lock- Assertion stage (Stage-2) and the Commitment Establishment stage (Stage-3). This document defines the Setup Phase, often called "Stage-0", prior to the execution of SATP Core. During Setup, the two Gateways that would participate in the asset transfer are bound together via a "transfer context". The transfer context conveys information regarding the assets to be exchanged. Gateway can perform any kind of negotiation based on that transfer context, before entering into SATP Core. "IPv6 Addresses for Ad Hoc Networks", Fred Templin, 2025-04-03, 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. "Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime", Tirumaleswar Reddy.K, Aritra Banerjee, 2025-05-28, Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). "An Analysis of ASPA-based AS_PATH Verification", Nan Geng, Mingqing(Michael) Huang, Yangyang Wang, 2025-02-20, Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. "Efficient RDAP Referrals", Gavin Brown, Andy Newton, 2025-05-19, This document describes how RDAP servers can provide HTTP "Link" header fields in RDAP responses to allow RDAP clients to efficiently determine the URL of related RDAP records for a resource. "Naming the Protocol specified RFC 8029", Loa Andersson, Mach Chen, Carlos Pignataro, 2025-05-28, RFC 8029 specifies the key MPLS Operation, Administration, and Maintenance protocol, sometimes referred to MPLS Label Switched Path (LSP) Ping, or MPLS LSP Ping. Howerver, the actual name of the protocol have never been explicitly specified or documented. This document corrects that omission. This document updates RFC 8029. "Operations, Administration and Maintenance (OAM) data collection for service decision-making in Computing-Aware Traffic Steering", Gao xing, Xinxin Yi, FUHUAKAI, 2025-01-05, This document describes the collection of OAM data for services decision-making in Computing-Aware Traffic Steering.In the following section, the main functional components and processes of OAM data collection will be elaborated in detail. "Media over QUIC - Transfork", Luke Curley, 2025-01-16, MoqTransfork is designed to serve live tracks over a CDN to viewers with varying latency and quality targets: the entire spectrum between real-time and VOD. MoqTransfork itself is a media agnostic transport, allowing relays and CDNs to forward the most important content under degraded networks without knowledge of codecs, containers, or even if the content is fully encrypted. Higher level protocols specify how to use MoqTransfork to encode and deliver video, audio, messages, or any form of live content. "MPLS Network Action for Deterministic Latency", Xueyan Song, Quan Xiong, Rakesh Gandhi, 2025-06-15, This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains. "Route Origin Registry Problem Statement", Shenglin Jiang, Ke Xu, Li Qi, Xingang Shi, Zhuotao liu, 2025-05-18, Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin ASes (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry. "Multicast Source Discovery Protocol (MSDP) Send Hold Timer", Yi Liu, Xiaolei Xu, Changwang Lin, 2025-02-15, This document defines the SendHoldTimer and the SendHoldTimer_Expires event in the MSDP protocol. The implementation of SendHoldTimer helps to address the situation where the local system detects that the remote system has not processed MSDP messages but has not terminated the MSDP session. According to this document, when the SendHoldTimer expires, the local system should close the MSDP session connection, rather than relying on the remote system to initiate the session closure. This document updates RFC3618. "Label Distribution Protocol (LDP) Send Hold Timer", Changwang Lin, HuangZhibo, 2025-02-15, This document defines the SendHoldTimer and SendHoldTimer_Expires event in the LDP protocol. The implementation of SendHoldTimer helps address situations where the local system detects that the remote system has not processed LDP messages but has not terminated the LDP session. The document specifies that when the SendHoldTimer expires, the local system should close the LDP session connection, rather than solely relying on the remote system for session termination. This document updates RFC5036. "Path Computation Element (PCE) Communication Protocol (PCEP) Send Hold Timer", Changwang Lin, 2025-02-15, This document defines the SendHoldTimer and SendHoldTimer_Expires events in the PCEP protocol. The implementation of SendHoldTimer helps address situations where a local system detects that a remote system has not terminated the PCEP session despite not processing PCEP messages. As per this document, when the SendHoldTimer expires, the local system should close the PCEP connection rather than solely relying on the remote system to terminate the session. This document provides updates to RFC5440. "SEARCH -- a New Slow Start Algorithm for TCP and QUIC", Jae Chung, Maryam Kachooei, Feng Li, Mark Claypool, 2025-03-17, TCP slow start is designed to ramp up to the network congestion point quickly, doubling the congestion window each round-trip time until the congestion point is reached, whereupon TCP exits the slow start phase. Unfortunately, the default Linux TCP slow start implementation -- TCP Cubic with HyStart [HYSTART] -- can cause premature exit from slow start, especially over wireless links, degrading link utilization. However, without HyStart, TCP exits slow start too late, causing unnecessary packet loss. To improve TCP slow start performance, this document proposes using the Slow start Exit At Right CHokepoint (SEARCH) algorithm [KCL24] where the TCP sender determines the congestion point based on acknowledged deliveries -- specifically, the sender computes the delivered bytes compared to the expected delivered bytes, smoothed to account for link latency variation and normalized to accommodate link capacities, and exits slow start if the delivered bytes are lower than expected. We implemented SEARCH as a Linux kernel v5.16 module and evaluated it over WiFi, 4G/LTE, and low earth orbit (LEO) and geosynchronous (GEO) satellite links. Analysis of the results show that the SEARCH reliably exits from slow start after the congestion point is reached but before inducing packet loss. "Architectural Considerations for Environmental Sustainability", Carlos Pignataro, Ali Rezaki, Suresh Krishnan, Jari Arkko, Alexander Clemm, Hesham ElBakoury, Shailesh Prabhu, 2025-05-12, This document describes several of the design tradeoffs involved in optimizing for sustainability along with the other common networking metrics such as performance and availability. "Sustainability Considerations for Networking Protocols and Applications", Carlos Pignataro, Ali Rezaki, Jari Arkko, Alexander Clemm, Hesham ElBakoury, Shailesh Prabhu, 2025-05-12, Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementers sustainability- related advice and guidance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. "OAuth Status Assertions", Giuseppe De Marco, Orie Steele, Francesco Marino, Marina Adomeit, 2024-12-20, Status Assertion is a signed object that demonstrates the validity status of a Digital Credential. These assertions are periodically provided to Holders, who can present these to Credential Verifier along with the corresponding Digital Credentials. The approach outlined in this document makes the Credential Verifier able to check the status, such as the non-revocation, of a Digital Credential without requiring to query any third-party entities. "IGP-based Source Prefix Advertisement for Intra-domain SAVNET", Lancheng Qin, Dan Li, Xueyan Song, Changwang Lin, 1211176911910469110103, 2025-03-15, SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS. "Gap Analysis, Problem Statement, and Requirements in AI Networks", PengFei Huo, Gang Chen, Changwang Lin, Zhuo Jiang, 2025-02-24, This document provides the gap analysis of AI networks, describes the fundamental problems, and defines the requirements for technical improvements. "A OSF Framework for Artificial Intelligence (AI) Network", PengFei Huo, Gang Chen, Changwang Lin, Huichen Dai, 2025-02-24, This document describes a framework for Artificial Intelligence (AI) network, Particularly, the document identifies a set of AI network components, describes their interactions, and exemplifies the workflow of the control and data planes. "Bgp Extension for Tunnel Egress Point", PengFei Huo, Gang Chen, Changwang Lin, Weiqiang Cheng, Syed Naqvi, Yossi Kikozashvili, 2025-03-03, In AI networks, flow characteristics often exhibit a low number of flows but with high bandwidth per flow, making it easy to cause network congestion when using traditional flow-level load balancing methods. Currently, the direction of traffic scheduling focuses on load sharing individual packets of the same flow, which requires sorting based on the Tunnel Egress Point information from the remote end. This document describes the method of publishing Tunnel Egress Point through the BGP protocol. "ICMP extension to include underlay information", Jaganbabu Rajamanickam, Darren Dukes, Madhan Sankaranarayanan, 2025-01-30, Network operators operating overlay networks require the ability to identify hops in an underlay network when traceroute in the overlay. This document defines an ICMP Error extension message to carry the underlay error information to the overlay network endpoint. "Deterministic Networking SRv6 Data Plane", Balazs Varga, Ferenc Fejes, 2024-12-18, This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and optionaly the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. "Deterministic Networking specific SID", Balazs Varga, Ferenc Fejes, 2024-12-18, Replication, Elimination and Ordering functions of the DetNet Architecture require packet sequence information (i.e., sequence number) to provide service protection by the DetNet service sub- layer. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed on packets of DetNet flows to support the specific service protection treatment. "STAMP Extensions for DetNet", Xiao Min, Shaofu Peng, Xiaoming He, 2025-06-09, Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. "Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network", Reza Rokui, Aihua Guo, Phil Bedard, Swamynathan Balasundaram, Gert Grammel, 2025-05-26, This draft outlines the pluggable module attributes within a host device. It includes representations of optical pluggable module capabilities, configuration, states, and telemetry data. These attributes draws from existing IETF standards and incorporates input from other industry forums and standards, such as ITU-T, OpenConfig, OIF and ONF TAPI, to ensure uniform structuring and consistent naming conventions. Note that the IETF terminology shall be given precedence wherever possible. In case there is a duplication of an attribute, this draft may describe how the attribute is named in the related document. Only if no attribute exists in IETF RFCs or IETF WG drafts, new attributes shall be introduced if they are needed. This draft provides a gap analysis with respect to existing IETF work in the following areas: * It provides an analysis of optical attributes provided by other organizations and identifying modeling gaps in current IETF drafts. * It identifies modeling needs addressing the specific aspect of pluggability of transceiver modules. The authors recognize the fact that that not all pluggable modules are coherent, not all coherent pluggable modules are DWDM capable and not all DWDM capable interfaces are implemented as pluggable modules. This analysis identifies gaps to manage the lifecycle of an optical pluggable module, from operator approval and viability assessment, to deployment, monitoring and phase-out. The lifecycle of an optical pluggable module, from operator approval and viability assessment to deployment and monitoring, is also addressed. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://italobusi.github.io/actn-wdm-pluggable-modelling/draft-rokui- ccamp-actn-wdm-pluggable-modelling.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- rokui-ccamp-actn-wdm-pluggable-modelling/. Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/. Source for this draft and an issue tracker can be found at https://github.com/italobusi/actn-wdm-pluggable-modelling. "Segment Routing Policy Extension for Network Resource Partition", Jiang Wenying, Ran Chen, Jie Dong, Changwang Lin, Ran Pang, KaZhang, wei gao, 2025-03-02, Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document describes how the SR Policy extension for associated NRP and the operational mechanisms function together. "On-Path Telemetry for Active Performance Measurements", Giuseppe Fioccola, Xiao Min, 2025-02-25, 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. "BGP Extensions of SR Policy for Composite Candidate Path", Jiang Wenying, Changwang Lin, Ran Chen, 2024-12-26, 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. "Filter of Configuration Change Notifications", Ran Chen, Gu ChunHua, Jia Rui, Li YunFang, 2025-03-03, 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. "Data Model for Computing-Aware Traffic Steering (CATS)", Huijuan Yao, Changwang Lin, 2025-03-02, This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) framework. "BGP SR Policy Extensions for Weight Time Range", Feng Yang, Changwang Lin, 2024-12-29, 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 candidate paths, each consisting of one or more segment lists. In the scenario where there are multiple segment list paths, traffic load balancing can be achieved based on the weight value assigned to each path. Typically, the weight value for each path is fixed. This document defines an extension of BGP SR Policy for setting the weight value for each path based on time range. "IGP Extensions for Optimized SRv6 SID Advertisement", Weiqiang Cheng, Liyan Gong, Changwang Lin, Louis Chan, 2024-12-25, When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance. "BMPS: Transport Layer Security for BGP Monitoring Protocol", Hemant Sharma, Steven Clarke, 2025-02-04, The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates [RFC7854] regarding BMP session establishment and termination. "FC-BGP Protocol Specification", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, Yangfei Guo, 2025-04-06, 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. "IGP Reverse Metric Algorithm", Peter Psenak, Jakub Horn, Les Ginsberg, 2025-01-02, IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. "Operational Guidance for Protection mechanisms in SRv6 Networks", Yao Liu, Jiang Wenying, Changwang Lin, Xuesong Geng, Yisong Liu, 2025-03-20, This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks. "IETF Experiments", Ron Bonica, Adrian Farrel, 2025-01-21, This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. "OAuth Client ID Metadata Document", Aaron Parecki, Emelia Smith, 2025-01-09, 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. "Intra-domain Source Address Validation (SAVNET) OAM", Weiqiang Cheng, Dan Li, Changwang Lin, 1211176911910469110103, 2025-02-15, This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. "Signaling SAVNET Capability Using IGP", Weiqiang Cheng, Changwang Lin, 1211176911910469110103, 2025-02-15, Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. "Attester Groups for Remote Attestation", Houda Labiod, Amine Lamouchi, zhang jun, Andrzej Duda, Henk Birkholz, 2025-04-18, This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. "Extensible Authentication Protocol (EAP) Using Privacy Pass Token", Paresh Sawant, Bart Brinckman, 2025-04-15, This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. "Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2", Christopher Dearlove, 2025-06-12, This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". "Adaptive Routing Framework", Weiqiang Cheng, Changwang Lin, Kevin Wang, Jiaming Ye, Rui Zhuang, PengFei Huo, 2025-04-24, In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. "Arm's Confidential Compute Architecture Reference Attestation Token", Simon Frost, Thomas Fossati, Giridhar Mandyam, 2025-03-03, The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. "Advertising Router Information", Zhaohui Zhang, Kevin Wang, Changwang Lin, Niranjan Vaidya, Jeff Tantsura, Yisong Liu, 2025-04-22, 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. "Constrained GeneRic Autonomic Signaling Protocol", Longwei Zhu, Sheng Jiang, Cheng Sheng, 2025-05-04, This document proposes the UDP-based Constrained GeneRic Autonomic Signaling Protocol (cGRASP), which is designed to be a constrained and lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. cGRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource- constrained devices dominate. Given the established ecosystem of CoAP and aiming to promote cGRASP adoption in IoT, this document also focuses on the cGRASP transition from UDP to a CoAP-based framework, i.e., CoAP-based cGRASP. Furthermore, this document also discusses the potential way to adapt the cGRASP to work on the network without IP connectivity. "Adaptive Routing Notification for Load-balancing", Yao Liu, lihesong, Wei Duan, 2025-06-12, In this document, adaptive routing is referred to as a technology that makes dynamic traffic forwarding decisions based on changes in traffic load and network topology, devices with adaptive routing capabilities can dynamically select the outport in the forwarding table based on the congestion condition of the outport or downstream link. This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered and processed in the network. "Optional IS-IS Fragment Timestamping", Tony Przygienda, Colby Barth, 2025-05-06, Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. "Fully Adaptive Routing Ethernet using BGP", Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Tiezheng, 2025-05-21, Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute the traffic to the same destination over multiple equal- cost paths, based on the network capacity and even congestion information along those paths. "OAM Requirements for Enhanced DetNet OAM", Jinjie Yan, Han Zhengxin, Xiangyang Zhu, 2025-02-20, This document describes the specific requirements of the Operations, Administration, and Maintenance (OAM) for Enhanced DetNet, and analyzes the gaps with the existing OAM methods. It describes related OAM solutions considerations as well. "Root CA Certificate Rekeying in the Scenario of Post Quantum Migration", Guilin WANG, Yanjiang Yang, Jie Zhang, 2025-04-22, 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. "Arm's Confidential Computing Architecture (Arm CCA) Attestation Verifier Endorsements", Yogesh Deshpande, Thomas Fossati, 2025-03-03, Arm Confidential Computing Architecture (CCA) Endorsements comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an Arm CCA system. 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/yogeshbdeshpande/draft-cca-rats-endorsements. "Outer Header Translator - multihoming", Naoki Matsuhira, 2025-01-06, This document describes how to achieve multihoming using OHT. This document describes both the use of provider addresses and provider independent addresses. "Pacing in Transport Protocols", Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen, 2025-03-03, 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. "Track Switching in Media over QUIC Transport", Zafer Gurel, Ali Begen, 2025-02-18, This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other. "YANG Data Models for fine grain Optical Transport Network", 谭艳霞, Zheng Yanlei, Italo Busi, Chaode Yu, XingZhao, 2025-04-15, This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. "A YANG Data Model for Resource Performance Monitoring", Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, Mingshuang Jin, 2025-01-03, This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. "A YANG Data Model for Service Path Computation", Chaode Yu, Sergio Belotti, Italo Busi, Aihua Guo, Dieter Beller, 2025-01-03, This document defines a YANG data model for client signal service's path computation and path management. "Logging over Media over QUIC Transport", Cullen Jennings, 2025-03-01, Real time systems often run into the problems where the network bandwidth for logging is 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 below the peak rate while not impacting 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", Cullen Jennings, Suhas Nandakumar, 2025-03-01, 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. This document specifies how to send metrics type information over the Media Over QUIC Transport (MOQT). "Upper limit values for DNS", Kazunori Fujiwara, 2025-02-28, There are parameters in the DNS protocol that do not have clear upper limit values. If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks, and several attack methods have been proposed. This draft proposes reasonable upper limit values for DNS protocols. "Source Prefix Advertisement for Intra-domain SAVNET", Dan Li, Nan Geng, Lancheng Qin, 2025-04-08, The new intra-domain source address validation (SAV) mechanism requires improving the accuracy (especially avoiding blocking legitimate traffic) and supporting automatic update (see [I-D.ietf-savnet-intra-domain-problem-statement]). To this end, this document proposes an intra-domain SAV mechanism, called source prefix advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for short), to advance the technology for intra-domain SAV. SPA-based SAVNET allows routers in an intra-domain network to exchange SPA information. By using SPA information and routing information, intra-domain routers can determine more accurate SAV rules in an automatic manner. "IGP Reverse Prefix Metric", Dan Li, Changwang Lin, Acee Lindem, Libin Liu, Xueyan Song, 2025-02-28, This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. "Semi-Private Messages in the Messaging Layer Security (MLS) Protocol", Rohan Mahy, 2025-04-21, 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. "PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters", Quynh Dang, Stephan Ehlen, Johannes Roth, Falko Strenzke, 2025-01-07, This document defines PQ/T composite schemes based on ML-KEM and ML- DSA combined with ECC algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol. "Benchmarking Methodology for Source Address Validation", Li Chen, Dan Li, Libin Liu, Lancheng Qin, 2025-05-20, This document defines methodologies for benchmarking the performance of 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. "A Framework and Definition for Collective Communication Offloading", Ran Chen, Kehan Yao, Changwang Lin, Chenqiang Gao, 2025-01-25, This document provides a definition of the term "Collective Communication Offloading" for use within the IETF and specifically as a reference for other IETF documents that describe or use aspects of Collective Communication Offloading. The document also describes the characteristics of an IETF Collective Communication Offloading, related terms and their meanings, and discusses the general framework for Collective Communication Offloading, the necessary system components and interfaces. "Integration of DNS Domain Names into Application Environments: Motivations and Considerations", Swapneel Sheth, Andrew Kaizer, Bryan Newbold, N. Johnson, 2025-01-16, This document reviews the motivations and considerations for integrating DNS domain names into an application environment and provides terminology to establish a shared understanding of what a DNS integration may entail. "Network Attestation for Secured foRwarding (NASR) Architecture", Peter Liu, Meiling Chen, Michael Richardson, Diego Lopez, 2025-03-03, This document provides an architecture overview of NASR entities, interactive procedures and messages. "Source Address Validation Enhanced by Network Controller", tongtian124, Changwang Lin, Nan Wang, 2025-03-02, Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. "YANG Data Model for Power-Group Aware TE Topology", Colby Barth, Vishnu Beeram, 2025-03-03, 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. "The Correspondence between Packets and SRv6 Tunnels", Jing Zhao, Wenxiang Lve, 2025-02-11, This paper introduces a new extension header, the SRv6 Policy Key, which addresses the issues of timeliness and accuracy in controller- aware path management within SRv6 networks. By adding a unique path identifier to the message header, this scheme enables network nodes to report path information to the controller. This ensures that the controller maintains a real-time and accurate view of the SR path status, even if the SID is lost during transmission or if the controller cannot monitor it in real time and accurately. The approach aims to enhance network availability and operational efficiency, particularly in scenarios involving multi-path tunnel configurations and load balancing. "RTP payload format for APV", Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi, 2025-02-28, This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APC) codec. "Challenge: Network Digital Twin - Practical Considerations and Thoughts", Marco Liebsch, Martin Stiemerling, Neil-Jocelyn Schark, 2025-03-03, This document focuses on practical challenges associated with the design, creation and use of Network Digital Twins. According to the identified challenges, a set of suitable functional elements are described to overcome some of these challenges. Experiences from the design, development and evaluation of an SDN-based Network Digital Twin are described and conclude this document. "Ethernet VPN (EVPN) Multicast Leave Synch Route Update", Jorge Rabadan, Olivier Dornon, 2025-01-10, The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) specification describes the procedures to synchronize IGMP/MLD membership report and leave group states in all the PEs that are attached to the same Ethernet Segment. In particular, the Multicast Leave Synch route described in the same specification, synchronizes the leave procedures on all the members of the Ethernet Segment, for a multicast group and for an amount of time (the Maximum Response Time). The use of the Maximum Response Time may be different depending on whether the local state was created by IGMPv2, IGMPv3 or MLDv2. In addition, the Maximum Response Time advertised in the Multicast Leave Synch route needs to account for the time that it takes for the route to be propagated in the network, which might not be easy to predict. This document clarifies the use of the Maximum Response Time and updates the procedures for the Multicast Leave Synch route. "Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile", Michael Jenkins, Alison Becker, 2025-04-21, This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for applications that use Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available for use by developers and operators of these and any other system deployments. "Parallel NFS (pNFS) Flexible File Layout Version 2", Thomas Haynes, 2025-05-22, 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 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 Mojette algorithm are used for data protection. "Mobile Traffic Steering", Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang, 2025-03-03, 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. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. "Intent for Green Services", Luis Contreras, Guillermo Illan, 2025-03-17, There is an increasing interest on incorporating sustainable dimension to the provision of commnunication services. This document describes an intent for allowing customers to express their desired intents in terms of the green service objectives they expect from the network provider. "On Numbers in CBOR", Carsten Bormann, 2025-01-08, The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers and implementers of CBOR libraries and of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is a rather drafty initial revision, pieced together from // various components, so it has a higher level of redundancy than // ultimately desired. "The Challenges and Requirements for Routing in Computing Cluster network", Fengkai Li, Yizhou Li, Rui Meng, Rachel Huang, 2025-02-28, This document explores the characteristics of computing cluster network and analyzes the challenges of employing the traditional distributed or centralized routing mechanisms in it. In order to achieve the enhanced scalability, improved resilience and optimized performance simultaneously, hybrid routing is briefly examined as a potential way to combine the advantages of distributed and centralized mechanisms. The document further shows the possible future work. "Deterministic Networking specific MNA", Greg Mirsky, Balazs Varga, 2025-01-21, In IETF, the Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. This document focuses on the MPLS Data Plane, namely, how to use MNA (MPLS Network Action) for DetNet flows, when forwarded over an MPLS technology-based network domain. "Distribution of Source Address Validation State in BGP", Jeffrey Haas, 2025-05-01, Source Address Validation (SAV) is a technique that can be used to mitigate source address spoofing. draft-huang-savnet-sav-table codifies the concept of source address validation on a per-incoming interface basis, the validation mode, and the traffic handling policy as a "SAV Table". This document defines a mechanism for distributing logical SAV Tables in BGP. This mechanism is addresses inter-domain SAV use cases. These SAV Tables may be used to implement appropriate device-specific validation for source addresses. "Framework for efficient Service Carving in EVPN Multihoming", Kiran Thimmappa, 2025-01-25, This document proposes a new approach for the Designated Forwarder (DF) selection algorithm. This is besides the existing algorithm types discussed in RFC7432 and RFC8584. A DF is a PE part of an Ethernet-Segment, forwarding BUM traffic to multi-homed hosts. This document discusses methods to achieve efficient service carving in Evpn Multi-homed networks by extending the DF selection algorithm type in RFC7432 by suggesting a new approach for service carving. "EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission", Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith, 2025-02-21, This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. "Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers", Paolo Lucente, Camilo Cardona, Mukul Srivastava, 2025-03-03, Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. "ASPA-based AS_PATH Verification for BGP Export", Jia Zhang, 2025-01-21, This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers. "Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)", FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, Bin Tan, 2025-02-25, This document proposes a flow-level load balancing solution for CATS, and is designed to effectively manage CS-ID traffic by addressing issues like frequent control plane operations and uneven use of computing resources. The approach entails concurrently identifying multiple next-hop choices, factoring in both network pathways and service instances. Traffic is then distributed among these service instances using flow-based load balancing, which relies on the five- tuple characteristics of packets. "Collision Free Keytags for DNSSEC", Mark Andrews, Shumon Huque, Yorgos Thessalonikefs, 2025-03-02, DNSSEC employs a Key Tag field in the RRSIG and DS resource records in order to efficiently identify the key that produced a DNSSEC signature and the key that should be used as a secure entry point into a delegated zone. The Key Tag was not intended to be a unique identifier. Key tag collisions can occur in practice for keys in the same zone, though they are relatively rare in normal operation. Colliding key tags impose additional work on a validating resolver because it then has to check signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they open up resolvers to computational denial of service attacks by adversaries deploying specially crafted zones with many intentionally colliding key tags. This document specifies updates to the DNSSEC protocol and the process of key generation to avoid colliding key tags. "EVPN Route Types and Procedures for EVN6", Chongfeng Xie, Jibin Sun, Xing Li, Guoliang Han, 2025-02-27, EVN6 is a mechanism designed to carry Ethernet virtual networks, providing Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 directly places the Ethernet frames in the payload of IPv6 packet, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. "An Interplanetary DNS Model", Scott Johnson, 2025-03-20, As human activity continues to spread beyond the Earth, so must the communications systems which support that activity continue to expand in scope. One such case, Internet naming, presents particular challenges when considering a multi-planet civilization. Proper operation of terrestrial DNS services and clients require constant, reasonably low latency connectivity to operate properly. These conditions are distinctly not present when considering interplanetary links; high latency and frequent disruption due to space weather events and general link availability prevail. To overcome these challenges in space networking, a delay and distruption tolerant (DTN) suite of protocols has been developed based on a store and forward mechanism, Bundle Protocol(BP). This DTN network, which optimizes to ensure bundle delivery, does not allow for end to end encapsulation of IP packets beyond terrestrial boundaries, as the latency still creates issues completing network transactions, even in the unlikely event of continuous link availability. "POSIX Draft ACL support for Network File System Version 4, Minor Version 2", Rick Macklem, 2025-06-12, This document describes a potential protocol extension involving the addition of four new attributes to be used by servers to provide support for POSIX ACLs. The term POSIX ACLs refers to the ACL component of the Portable Operating System Interface (POSIX) 1003.1e draft 17 document for which sponsorship was withdrawn in January 1998. Although the draft POSIX standard that describes these ACLs was never ratified, several POSIX-based operating systems, such as Linux, Solaris and FreeBSD include support for them. The NFS Version 4 (NFSv4) ACLs described in Network File System (NFS) Version 4 Minor Version 1 henceforth referred to as NFSv4 ACLs, use a different model and attempts to map between the ACLs of these two models have not been completely successful. In order to adequately support POSIX ACLs, this document proposes four new attributes that may optionally be used by an NFS Version 4, minor version 2 (NFSv4.2) server to support ACLs that conform to the aforementioned POSIX 1003.1e draft 17. "A Top-level Domain for Private Use", Kim Davies, Andrew McConachie, Warren Kumari, 2025-03-03, This document describes the "internal" top-level domain for use in private applications. "An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems", Jaehoon Jeong, Patrick Lingga, J., PARK, Diego Lopez, Susan Hares, 2025-02-13, 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]. "I2NSF Analytics Interface YANG Data Model for Closed-Loop Security Control in the I2NSF Framework", Patrick Lingga, Jaehoon Jeong, Yunchul Choi, 2025-02-13, 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-i2nsf-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]. "The Internet Standards Process", Rich Salz, Scott Bradner, 2025-04-07, 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 RFC2026, RFC6410, RFC7100, RFC7127, RFC8789, and RFC9282. It updates RFC5657. It also includes the changes from RFC7475, and with [bis2418], obsoletes it. "Organization Trust Relationship Protocol", Ralph Brown, 2025-02-02, This document specifies the "Organization Trust Relationship Protocol" method for service owners (organizations) to express in a standard format their trusted relationships with other organizations, as well as identify the social networks they control. This method was originally defined by Scott Yates in 2020 for this purpose. "IETF Working Group Guidelines and Procedures", Rich Salz, Scott Bradner, 2025-04-07, 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 [bis2026], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. "Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design", Lionel Tailhardat, Raphael Troncy, Yoan Chabot, Fano Ramparany, Pauline Folz, 2025-05-15, Operational efficiency in incident management on telecom and computer networks requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge graphs can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management (ITSM) Knowledge Graph (KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. "PCE Communication Protocol (PCEP) extensions for updating Open Message content", Andrew Stone, Cheng Li, Samuel Sidor, 2025-02-25, This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to update information previously exchanged during PCEP session establishment via the Open message. "Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications", Joe Harvey, Burt Kaliski, Andrew Fregly, Swapneel Sheth, 2025-02-21, This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. "Hierarchical Deterministic Keys", Sander Dijkhuis, 2025-01-19, Hierarchical Deterministic Keys enables managing large sets of keys bound to a secure cryptographic device that protects a single key. This enables the development of secure digital identity wallets providing many one-time-use public keys. Some instantiations can be implemented in such a way that the secure cryptographic device does not need to support key blinding, enabling the use of devices that already are widely deployed. "Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2)", Jun Hu, Yasufumi Morioka, Guilin WANG, 2025-05-01, One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptographic algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. "Secure Key Integration Protocol (SKIP)", Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo, 2025-03-02, This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. "A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) Integrity Protected Options", Justin Iurman, Tianran Zhou, 2025-02-28, In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. I-D.ietf-ippm- ioam-data-integrity defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the configuration of these Integirty Protected Options. "Sockets API Extensions for In-kernel QUIC Implementations", Long Xin, Moritz Buhl, Marcelo Leitner, 2024-12-29, This document describes a mapping of In-kernel QUIC Implementations into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new QUIC features, and a consolidated error and event notification scheme. In-kernel QUIC enables usage for both userspace applications and kernel consumers. "BGP Extension for SRv6 Policy Segment List optimization", Yisong Liu, Changwang Lin, Ran Chen, 2025-02-20, In some use cases, an SRv6 policy's segment 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 document specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. This optimization can improve the forwarding efficiency of data packets when End SID and Service SID are present. "BGP SR Policy Extensions for Administrative Flags", Changwang Lin, Jinming Li, Ran Chen, 2025-02-20, 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 candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. "A method for delivery of SMTP messages over Bundle Protocol networks.", Scott Johnson, 2025-03-18, Delay and disruption tolerant networks are a foundational component of Interplanetary Internet communications. This document will treat several methods and modes of operation of Mail Transfer Agents in concert with Bundle Protocol Agents which allow SMTP interoperability between discrete IP networks bridged by DTNs, via Application Layer Gateways. "Knowledge Graph Framework for Network Operations", Michael Mackey, Benoit Claise, Thomas Graf, Holger Keller, Dan Voyer, Paolo Lucente, Ignacio Martinez-Casanueva, 2025-03-04, This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. 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/mike-mackey. "Adding an Uncacheable Attribute to NFSv4.2", Thomas Haynes, 2025-03-21, The Network File System version 4.2 (NFSv4.2) allows a client to cache both metadata and data for file objects, as well as metadata for directory objects. While caching directory entries (dirents) can improve performance, it can also prevent the server from enforcing access control on individual dirents. Similarly, caching file data can lead to performance issues if the cache hit rate is low. This document introduces a new uncacheable attribute for NFSv4. Files and dirents marked as uncacheable MUST NOT be stored in client-side caches. This ensures data consistency and integrity by requiring clients to always retrieve the most recent data directly from the server. This document extends NFSv4.2 (see RFC7862). "IS-IS Extension for Big TLV", Aijun Wang, Huaimo Chen, Jie Dong, Changwang Lin, Gyan Mishra, 2025-02-17, The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a solution to IS-IS extension for encoding the TLV whose value is bigger than 255 octets. "BGP FlowSpec Extension for Traffic Scheduling", Huiyue Zhang, Zhuojun Huang, Cancan Huang, 2025-03-16, Traditional QoS technology can not achieve fine adjustment in the traffic scheduling, and has a large amount of configuration and poor maintainability. BGP FlowSpec technology provides a wealth of filtering conditions and processing actions, using BGP network layer reachable information (NLRI) to transmit traffic filtering information, which can achieve a more fine-grained control of the traffic and improve maintainability. This document defines the extension of BGP FlowSpec, adding two new traffic filtering actions for extended community: minimum rate guarantee and congestion management, to enable better management and scheduling of traffic, and further improving the scalability and applicability of BGP FlowSpec. "DNS to Web3 Wallet Mapping", Shay Chin, 2025-02-18, This document proposes a implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security. "Addition of Extended DNS Errors codes", Stephane Bortzmeyer, 2025-01-06, This document is the specification of three new EDE (Extended DNS Errors) codes, for minimal answers, local roots and tailoring based on the client IP address. "CATS BGP Extension", Cheng Li, Peng Liu, 2025-04-03, 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). "Stateless MNA-based Egress Protection (SMEP)", Fabian Ihle, Michael Menth, 2025-06-13, The MPLS Egress Protection Framework specifies a fast reroute framework for protecting IP/MPLS services. To that end, bypass tunnels have to be signaled to the Point of Local Repair (PLR). Further, the PLR must maintain the bypass forwarding state on a per- transport-tunnel basis. This document presents the concept of Stateless MNA-based Egress Protection (SMEP). SMEP protects egress routers by providing alternative MPLS egress labels in-stack. This mechanism does not require a bypass forwarding state in PLRs. An example for the application of SMEP is given using a MPLS network action for stack management. "TOTP Secure Enrollment", Brian Contario, 2025-03-27, This document describes a secure key exchange scheme that extends the Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment method to prevent compromise of the non-expiring TOTP key by photographic capture of the QR code or by intentional or unintentional persistence of the key string in email, SMS, or other systems outside of the TOTP authenticator system itself. "Using BMP over QUIC connection", Yisong Liu, Changwang Lin, Thomas Graf, Paolo Lucente, 2025-02-19, The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. "RPKI Repository Problem Statement and Analysis", Dan Li, Li Chen, Yingying Su, Yu Fu, 2025-02-25, With the widespread deployment of Route Origin Authorization (ROA) and Route Origin Validation (ROV), Resource Public Key Infrastructure (RPKI) is vital for securing inter-domain routing. RPKI uses cryptographic certificates to verify the authenticity and authorization of IP address and AS number allocations and the certificates are stored in the RPKI Repository. This document conducts the data-driven analysis of the RPKI Repository, including a survey of worldwide AS administrators and a measurement and analysis of the existing RPKI Repository. This document finds that the current RPKI Repository architecture is sensitive to failures and lacks of scalability. An attack or downtime of any repository Publication Point (PP) will prevent RPs from obtaining complete RPKI object views. Furthermore, since the current RPKI Repository is not tamper-resistant, RPKI authorities can easily manipulate RPKI objects without consent from subordinate INR holders. This document also defines the key requirements for a reliable, scalable, and secure RPKI Repository. "Extending YANG modules at runtime", Michael Richardson, 2025-03-31, This document describes a mechanism of signaling extensions to YANG modules that can be used when YANG is not used in an online fashion. "Problem Statement with Aggregate Header Limit for IPv6", Yao Liu, Yisong Liu, 2025-05-26, This document first proposes introduces the concept "Aggregate header limit for IPv6"(IPv6-AHL) based on [RFC8883] 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. "Hybrid-Function-Chain (HFC) Framework", Dongyu Yuan, Yan Zhang, Daniel Huang, Chuanyang Miao, 2025-04-15, With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, a Hybrid-Function-Chain (HFC) framework is proposed in this draft, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning. "Segment Routing Policy-Based Source Address Validation (SAV) Mechanism", Xueting Li, Aijun Wang, Wei Wang, Yuanyuan Zhang, 2025-04-08, This draft proposes a novel mechanism for Source Address Validation (SAV) message propagation based on Segment Routing policies (SR- policy). Traditional SAV mechanisms often rely on routing tables (RIB) and Policy-Based Routing (PBR), but these methods lack the flexibility and granularity needed for some network environments. By leveraging the flexibility and control capabilities of SR-policy, the proposed mechanism ensures that SAV messages are propagated along well-defined paths, ensuring efficient, secure, and accurate source address validation. "PAKE Usage in TLS 1.3", Wei Guo, Liang Xia, Ji Li, 2025-02-24, This document provides a mechanism that uses password-authenticated key exchange (PAKE) as an authentication and key establishment in TLS 1.3, and that supports PAKE algorithms negotiation. "Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6)", Liyan Gong, Changwang Lin, Zheng Zhang, 2025-04-24, This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment. "Secure SMTP/TLS SRV Announcement", Steffen Nurpmeso, 2025-02-13, This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. "DKIM Hash Algorithm Adaptivity", Steffen Nurpmeso, 2025-02-02, DKIM (RFC 6376, section 3.7) defines how "data-hash" is generated as input to a "sig-alg" for the purpose of generating a cryptographic signature. Different to the RSA algorithm (RFC 8017) solely defined for and by DKIM at the time of its creation, modern signature algorithms, for example EdDSA (RFC 8032), include extensive data hashing as part of the signing process. For these algorithms it may make sense not to create a "data-hash", but to use the entire data as input to "sig-alg". This specification allows DKIM signing algorithms "data-hash" adaptivity, taking advantage of algorithm design, and digital signature API reality. "DKIM Signing Algorithm AdaEd25519-SHA256", Steffen Nurpmeso, 2025-02-02, This specification adds the DKIM (RFC 6376) signing algorithm AdaEd25519-SHA256. It is identical to Ed25519-SHA256 (RFC 8463) except for its use of DKIM hash algorithm adaptivity. Private and public keys are identical, and can be used interchangeably. "Privacy Primer for vCon Developers", Diana James, Thomas McCarthy-Howe, 2025-04-11, This document serves as a primer for technical professionals involved in managing personal data, including biometric information from audio and video recordings, and other sensitive information in messaging or personal communications. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, and disclosure of consumer data. The document covers fundamental privacy principles, defines important roles in data processing, and explains consumer rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address consumer data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices. "Current State of the Art for High Performance Wide Area Networks", Daniel King, Tim Chown, Chris Rapier, Daniel Huang, 2025-01-08, High Performance Wide Area Networks (HP-WANs) represent a critical infrastructure for the modern global research and education community, facilitating collaboration across national and international boundaries. These networks, such as Janet, ESnet, GÉANT, Internet2, CANARIE, and others, are designed to support the general needs of the research and education users they serve but also the the 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, big data analysis, AI training and massive industrial data analysis. "ML-KEM Security Considerations", Scott Fluhrer, Quynh Dang, John Mattsson, Kevin Milner, Daniel Shiu, 2025-05-15, NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely. "Discovery of Network Rate-Limit Policies (NRLPs)", Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Gyan Mishra, Markus Amend, Luis Contreras, 2025-04-27, This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs. "Automated Certificate Management Environment (ACME) Extension for Public Key Challenges", Feng Geng, Panyu Wu, Liang Xia, 2025-03-03, This document specifies an extension to the ACME protocol [RFC8555] that enables ACME servers to use the public key authentication protocol to verify the certificate applicant's control of the identity and to ensure strong consistency between the final certificate issued and the identity of the application order. A process extension for removing CSR at the certificate application phase is also proposed in this document. "Handling inter-DC/Edge AI-related network traffic: Problem statement", Antoine Fressancourt, Luigi Iannone, David Lou, Dirk Trossen, 2025-04-11, The growth in terms of number of parameters of LLM models as well as the need to use or train those models with private or protected data will require service providers operating LLM-based services to cooperate to train, specialize or serve LLM-based services accross datacenters. Given their structure, the number of parameters they incorporate and the collective communication librairies they are built with, LLM training and inference (or serving) network traffic has specific characteristics. In that regard, understanding the specificities of AI-related workloads is critical to determine how to operate AI-based services in a federated setting across datacenters. "Detecting Unwanted Location Trackers", Brent Ledvina, Zachary Eddinger, Ben Detwiler, Siddika Polatkan, 2025-05-29, This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. "Terminology for Energy Efficiency Network Management", Peter Liu, Mohamed Boucadair, Qin WU, Luis Contreras, Marisol Amador, 2025-06-14, Energy-efficient network management is primary meant to enhance conventional network management with energy-related management capabilities to optimize the overall energy consumption at the level of a network. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network element and their components. This document is defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. "Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications", Munhwan Choi, Younghwan Choi, 2025-02-25, 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. "ICMP Extension Header Length Field", Ron Bonica, Xiaoming He, Xiao Min, Tal Mizrahi, 2025-02-23, The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. "IGP Flex Soft Dataplane", Les Ginsberg, Peter Psenak, Zheng Zhang, 2025-04-13, 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. "Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification", Kotikalapudi Sriram, Nan Geng, Amir Herzberg, 2025-04-23, Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. "A Profile for Autonomous System Relationship Authorization (ASRA)", Nan Geng, Kotikalapudi Sriram, Mingqing(Michael) Huang, 2025-04-15, 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. "PQ/T Hybrid Composite Signatures for JOSE and COSE", Lucas Prabel, Sun Shuzhou, John Gray, 2025-06-15, This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. "COSE Receipts with CCF", Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Amaury Chamayou, 2025-06-03, This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced via Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees. "A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks", Mark Grayson, Joshua Redmore, 2025-05-29, This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to provide servers information pertaining to the operation of an IEEE 802.11 wireless network. The document has been developed by the Wireless Broadband Alliance's Access Network Metrics project team. This project was formed to addresses the adoption of RADIUS used to support Wi-Fi authentication in environments that are increasingly complex; with multiple possible overlapping networks, operating using different Wi-Fi technology generations, utilizing varied spectrum allocations, and where the AAA provider wants to ensure their users are getting a great Wi-Fi experience. In such environments, the Wi-Fi industry can benefit from a consistent framework that provides visibility of Wi-Fi network metrics, increasing confidence in Wi-Fi to support carrier use-cases, and consequently driving adoption. The use of a well defined syntax for the Connect-Info attribute that simultaneously supports existing Wi-Fi implementations while also addressing new requirements may have wider applicability by the broader Wi-Fi community. This document is an independent submission. It is not an IETF standard and does not have IETF consensus. "BGP - Link State (BGP-LS) Advertisement of BGP Egress Peer Engineering Performance Metric Extensions", Yisong Liu, Changwang Lin, Jinming Li, 104101, 2025-04-24, This document specifies a method for advertising BGP Egress Peer Engineering (EPE) Traffic Engineering (TE) Performance Metric information via BGP-LS. "The Mojette Transformation for the Erasure Coding of Files in NFSv4.2", Thomas Haynes, Pierre Evenou, 2025-03-19, Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flex file layout type version 2 further allows for erasure encoding types to provide data integrity. In this document, a new erasure encoding type for the Mojette Transformation is introduced. "MASQUE extension for signaling throughput advice", Lars Ihlar, Mirja Kuehlewind, 2025-03-03, 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)", Samuel Sidor, Zafar Ali, Cheng Li, Mike Koldychev, 2025-03-03, 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 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 * Allowing instantiation of LSP and optionally do fallback to Binding label/Segment Identifier (SID) allocation by the PCC when the binding value specified by the PCE is unavailable These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. "Secure UAS Stateless Network RID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2025-04-18, 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. "Convertible Forms with Multiple Keys and Signatures For Use In Internet X.509 Certificates", Sun Shuzhou, Yidi He, Hsiao-Ying Lin, 2025-04-22, This document presents a hybrid key and signature solution, which allows to integrate two public keys and/or two signatures into a single certificate. The scheme enables a single certificate to be converted between different forms, allowing an alternative public key and/or an alternative signature to be transmitted either by direct inclusion or by referencing external data. This flexibility ensures that the scheme is backward-compatible with legacy devices, while also providing enhanced security support for upgraded devices. Four CSR attributes and two new X.509v3 certificate extensions are defined, and the procedures for signing and verifying certificates containing the defined attributes and extensions are described. "Simple Local Web PKI Certificate Resource Preservation Management for Internet Browser", Penghui Liu, Yu Fu, Meiling Chen, Xiang Liu, Yu Zhang, 2025-06-16, The management of Web PKI certificate resources presents a challenge when the misalignment of ownership and management rights over certificate resources of one organization creating a risk of unilateral suspension and revocation by another competing organizations. This situation undermines the stability of critical infrastructure and affects the integrity of authentication systems. To address these concerns, this document proposes a mechanism that allows Internet browsers to create a customized management view of certificate resources, enabling them to override the verification results from specific certification authorities as needed. This approach enhances security, facilitates stakeholder collaboration, and preserves the operational integrity of foundational industry systems. "Automated Certificate Management Environment (ACME) Profiles Extension", Aaron Gable, 2025-04-18, This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. "A mechanism of security monitoring and management for service resources in Computing-Aware Traffic Steering (CATS)", LU Li, Meiling Chen, Li Su, 2025-04-23, This draft proposes a mechanism to realize monitoring and management of service resources. "Advertising Flexible Algorithm Extensions in BGP Link-State", Shraddha Hegde, Aravind MahendraBabu, Ketan Talaulikar, Peter Psenak, Bruno Decraene, 2025-04-10, 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. "Homomorphic Cryptography Protocols for Measurement Information Collection", Lun Li, Fei Liu, 2025-04-18, Homomorphic encryption is an algorithm that allows computations to be performed on encrypted data without first having to decrypt it. This document provides a homomorphic cryptographic protocol that supports addition and multiplication in the ciphertext state. In this document, the proposed protocol can be used to protect user privacy in measurement information collection and statistics by using homomorphic encryption. And let the collector server receive the computation results without having to acknowledge the information plaintext of each individual client. "IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method", Xiaoming He, Frank Brockners, Haoyu Song, Giuseppe Fioccola, Aijun Wang, 2025-02-26, In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. "Perceptive Routing Information Model", Tianran Zhou, Dan Li, Xuesong Geng, 2025-04-21, This docuement defines the information model for perceptive routing, which could serve as a foundational component in the implementation of perceptive routing. "Pisces: Real-Time Video Transport Framework", Jiaqi Zheng, Feida Liu, Yu Liu, Yi Lu, Guihai Chen, 2025-04-20, This document specifies the Pisces, an ensemble video transport framework for real-time communication. Pisces complements the benefits of rule-based and learning-based approaches, without modifying the codec layer. Pisces uses an incremental and iterative reinforcement learning model to adapt to the unseen environment. When the real environment well matches the training environment, the learning-based approach is actively working. Otherwise, the rule- based approach is used to ensure transport safety. By simultaneously leveraging both rule-based logic and learning models to proactively probe network capacity, Pisces achieves high efficiency in both single-flow and cross-flow scenarios, while ensuring stable and fair cross-flow convergence. Pisces can be deployed in WebRTC, which replaces the default Google congestion control algorithm. "Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3", Alison Becker, 2025-03-03, This document defines a base profile of TLS 1.3 for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ TLS 1.3. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. "ICMP Extensions for Environmental Information", Carlos Pignataro, Jainam Parikh, Ron Bonica, Michael Welzl, 2024-12-28, This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental sustainability information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental sustainability metrics. "Environmental Sustainability Terminology and Concepts", Carlos Pignataro, Ali Rezaki, Hesham ElBakoury, Shailesh Prabhu, 2025-05-12, This document defines a set of sustainability-related terms and concepts to be used while describing and evaluating the negative and positive environmental sustainability impacts and implications of Internet technologies. "RTP Payload for V-DMC", Hyunsik Yang, Xavier de Foy, 2025-03-19, This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. "Provider Independent Addresses Aggregation", Naoki Matsuhira, 2025-04-13, 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", XingZhao, Minxue Wang, Daniele Ceccarelli, Bo Wu, Chaode Yu, 2025-02-28, 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. "Domain Connect Protocol - DNS provisioning between Services and DNS Providers", Pawel Kowalik, A Blinn, Jody Kolker, S Kerola, 2025-03-03, This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. "Client Authentication Recommendations for Encrypted DNS", Tommy Jensen, Jessica Krynitsky, Jeffrey Damick, Matt Engskow, Joe Abley, 2025-04-14, Some encrypted DNS clients require anonymity from their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols. "Computing Aware Traffic Steering (CATS) with Generic Metric", Dongyu Yuan, Fenlin Zhou, Daniel Huang, Qiudong Chen, Chunning Dai, 2025-05-05, Steering traffic for computing-related services considering computing resources and circumstances is discussed in CATS WG. Correspondingly, publishing services and updating computing conditions turns out to be a significant issue. It SHOULD be realized that multiple same common metrics are required from both network and service instances in order to evaluate overall performance and further achieve and fulfill appropriate traffic steering and scheduling. Therefore, an implementation for distributed CATS with generic metrics delivery and distribution based on BGP is proposed and discussed in this draft. "SR based Loop-free implementation", Lijie Deng, Yongqing Zhu, Xuesong Geng, Zhibo Hu, 2025-03-02, Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. "Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type", Peter Liu, Mike Ounsworth, Michael Richardson, 2025-03-03, This document describes an approach where an ACME Server can challenge an ACME Client to provide a Remote Attestation Evidence or Remote Attestation Result in any format supported by the Conceptual Message Wrapper. The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. "Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing", Kuon Akiyama, Ryoichi Shinkuma, 2025-04-20, 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. "Advertisement of Multi-Sourced SAV Rules using BGP Link-State", tongtian124, Dan Li, Nan Geng, Nan Wang, Shunwan Zhuang, Jing Zhao, 2025-04-22, This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rules monitoring and management. "Extensions to IOAM Trace Option for Carrying Fixed-Size Data", Xiao Min, Yisong Liu, Changwang Lin, 2025-04-18, 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 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 transited IOAM-capable nodes. "Framework for Implementing Lossless Techniques in Wide Area Networks", Tao He, Hang Shi, Han Zhengxin, Gao xing, Tianran Zhou, 2025-04-20, This document proposes a comprehensive framework to address the challenges of efficient, reliable, and cost-effective large volume data transmission over Wide Area Networks (WANs). The framework focuses on planning and managing traffic paths, network slicing, and utilizing multi-level network buffers. It introduces dynamic path scheduling and advanced resource allocation techniques to optimize network resouce and minimize congestion. By leveraging cross-device buffer coordination and real-time adjustments, the framework ensures high throughput and low latency, meeting the demands of modern, data- intensive applications while providing a robust solution for large- scale data transmission. "A YANG Data Model of Performance Management Streaming", Bin Yoon, 2025-04-07, 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. "Post-Handshake Authentication via PAKE for TLS 1.3", Wei Guo, Liang Xia, Ji Li, 2025-02-24, This document provides a mechanism that uses password-authenticated key exchange (PAKE) as a post-handshake authentication for TLS 1.3, and that supports PAKE algorithms negotiation and optional channel binding. "Populating a list of YANG data nodes using templates", Robert Peschi, Shiya Ashraf, Deepak Rajaram, 2025-03-03, This document presents a modeling technique for configuring large scale devices in a compact way, when the device contains many similar data node patterns. A device here refers to any such entity that acts as a netconf server. This is realized by instructing the device to locally generate repetitive patterns of data nodes from a master copy called 'template' that is configured in the device. This approach is both convenient and efficient, as it minimizes the size of the running data store and reduces network provisioning time. It leverages existing YANG specification features and can be implemented with standard, off-the-shelf tools.The concept that is described in this draft does not aim to be a standard track document and does not cover the template solution that is currently being discussed within ietf netmod. "SCONE Real Time Communication Requirement", Hang Shi, Xuesong Geng, Qiangzhou Gao, Qinghua Wu, Jiaxing Zhang, 2025-04-20, In real-time communication (RTC) applications, low latency is essential, but unstable network conditions make it challenging. Traditional control loop reacts slowly and inaccurately to network changes. A new approach is proposed, communicating bandwidth and queue information from the bottleneck to the end-host for more accurate control. "Automation Scenarios and Requirements for Autonomous Networking (AN) Level 4", Chaode Yu, Yang Zhao, liuyucong, 2025-03-02, This document describes a scenario of OTN-WDM service automation and collaboration in transport networks and defines related functional requirements for domain controller. "Serialization of MoQ Objects to Files", Cullen Jennings, 2025-03-02, 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. "Applicability of TVR YANG Data Models", Li Zhang, Jie Dong, Mohamed Boucadair, 2025-02-28, 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. "Calibration of Measured Time Values between Network Elements", Luis Contreras, 2025-03-03, Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. This draft proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. "Inter-domain Source Address Validation (SAVNET) OAM", Weiqiang Cheng, Dan Li, Changwang Lin, 1211176911910469110103, 2025-04-24, This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. "Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane", Yisong Liu, Xuesong Geng, Changwang Lin, 2025-04-24, This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability. "DHCPv4 Option for IPv4 routes with IPv6 nexthops", David Lamparter, Tobias Fiebig, 2025-04-23, As a result of the shortage of IPv4 addresses, installations are increasingly recovering IPv4 addresses from uses where they are not strictly necessary. One such situation is in establishing next hops for IPv4 routes, replacing this use with IPv6 addresses. This document describes how to provision DHCP-configured hosts with their routes in such a situation. // This draft lives at https://github.com/eqvinox/dhc-route4via6 "Dynamic Network Adjustments for Cloud Service Scaling", Linda Dunbar, Chongfeng Xie, Kausik Majumdar, Bo Wu, Qiang Sun, 2025-01-24, This document defines a framework for dynamically adjusting network- wide load balancing policies in response to cloud service scaling events, addressing key challenges faced by Telecom Cloud Service Providers (TCSPs). As cloud services scale, increase traffic, or relocate workloads across distributed edge and core clouds, network policies must adapt in real time to maintain optimal performance and ensure compliance with strict service level objectives (SLOs). Current manual network adjustments are often slow, error prone, and insufficient for the dynamic nature of cloud environments. "Signalling Key State Via DNS EDNS(0) OPT", Erik Bergstrom, Leon Fernandez, Johan Stenstam, 2025-02-07, This document introduces the KeyState EDNS(0) option code, to enable the exchange of SIG(0) key state information between DNS entities via the DNS protocol. The KeyState option allows DNS clients and servers to include key state data in both queries and responses, facilitating mutual awareness of SIG(0) key status between child and parent zones. This mechanism addresses the challenges of maintaining synchronization of SIG(0) keys used for securing DNS UPDATE messages, thereby enhancing the efficiency and reliability of DNS operations that require coordinated key management. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-opt-transaction-state (https://github.com/johanix/draft-berra-dnsop-transaction-state-00). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. "Simple Time Over MoQ Protocol (STOMP)", Shamim Pirzada, 2025-03-02, This document describes Simple Time Over MoQ Protocol (STOMP), a protocol for sending the local time and, optionally, location information via Media Over QUIC Transport (MOQT) protocol [I-D.ietf-moq-transport]. Such information enables observing endpoints to measure latencies and monitor health of MOQT delivery network from different geographical locations. "A Password Authenticated Key Exchange Extension for TLS 1.3", Laura Bauman, David Benjamin, Samir Menon, Christopher Wood, 2025-02-11, The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. "Requirements for Energy Efficiency Management", Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, 2025-01-21, This document delineates the requirements for standards specifications in Energy Efficiency Management, extending the foundational work of RFC6988 and incorporating recent insights from operator requirements and the GREEN BoF discussions. Eleven years after the publication of RFC6988, this document reassesses and updates the requirements to align with contemporary needs. The primary objectives of this draft, which are listed in the goals and scope with the creation of the GREEN WG charter, is focusing on two main targets: (1) collecting and updating requirements for the management of energy-efficient networks, and (2) defining use cases for managing energy-efficient networks. This draft merges the drafts [rfc6988bis-green] and [green-bof-reqs]. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-terms-ucs-and-reqs "MoQ Media Interop", Jorge Ferret, Alan Frindell, 2025-03-15, This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT], using LOC[loc] packaging. "DKIM2 Why DKIM needs replacing, and what a replacement would look like", Bron Gondwana, Richard Clayton, Wei Chuang, 2025-03-03, This memo provides a rationale for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. "Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness", Jen Linkova, 2025-03-03, When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Similarly, in some scenario a link attachement for the host may change without the host detecting it. In both cases the host does not receive any signals to trigger the network stack configuration refresh, so it may continue to use "old" addresses which are not valid for the link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC. "VCON for MIMI Messages", Rohan Mahy, 2025-02-24, This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (MIMI) content format. "BGP Route Type Capability", Krishnaswamy Ananthamurthy, Mankamana Mishra, Lukas Krattiger, Keyur Patel, Jeffrey Haas, Daniel Schatte, 2025-05-07, BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. "Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) )", Donald Eastlake, Johan Stenstam, 2025-03-03, This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based authentication of DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. "DHCP Option Concatenation Considerations", Tommy Jensen, Milan Justel, 2025-03-03, DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by RFC 3396. However, this mechanism was defined to require support for all option types. This has led to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences. "Robots Exclusion Protocol Extension to communicate AI preferences vocabulary", Fabrice Canel, Krishna Madhavan, 2025-04-04, This document extends the RFC9309 by facilitating the communication of content usage specifically within the area of Artificial Intelligence (AI). "RPKI to Router Protocol over QUIC", 1211176911910469110103, Changwang Lin, ROY Jishnu, Di Ma, Yisong Liu, 2025-06-08, The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides useful and secure semantics for RTR Protocol in particular as a single connection could carry multiple requests over streams, enabling much better efficiency and performance for both peers. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. "SCONE Privacy Properties and Incentives for Abuse", Anoop Tomar, Wesley Eddy, Abhishek Tiwari, Matt Joras, 2025-05-07, This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. "APIs To Expose SCONE Metadata to Applications", Wesley Eddy, Abhishek Tiwari, Alan Frindell, 2025-05-08, This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using SCONE protocol signalling, it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. "SCONE Need for Defining A New On-Path Signaling Mechanism", Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras, 2025-05-07, This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). "SCONE Video Optimization Requirements", Matt Joras, Anoop Tomar, Abhishek Tiwari, Alan Frindell, 2025-05-12, These are the requirements for the "Video Optimization" use-case for the SCONE topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. "Means of Compliance for DRIP Entity Tags as UAS RID Identifiers", Adam Wiethuechter, 2025-05-07, This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. "DNS Filtering Details for Applications", Mark Nottingham, 2025-02-21, [I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism that enable applications to convey the details of some filtering incidents to their users. 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/mnot/public-resolver-errors. "Traceability Claims", Michael Prorock, Michael Jones, 2025-04-16, 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). "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", Damien Saucez, Luigi Iannone, 2025-03-03, This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP control plane elements generically called "DDT Nodes". Each DDT Node is configured as "authoritative" for one or more EID-Prefixes, along with the set of RLOCs for Map-Servers or "child" DDT Nodes to which more-specific EID-Prefixes are delegated. This document obsoletes RFC 8111 and updates RFC 9301. "BMP State Summaries", Paolo Lucente, Camilo Cardona, Colin Petrie, Luuk Hendriks, 2025-03-01, BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The main issue is that the ability to correctly parse BGP Update PDUs, carried in BMP Route Monitoring messages, depends on the BGP Capabilities exchanged during the establishment of the BGP session between the peers via BGP Open PDUs. The BGP Open PDUs, carried in BMP Peer Up Notification messages, are exported at the establishment of the BMP session. Similar to BGP, BMP sessions are typically long-lived, so the crucial information to correctly parse subsequent messages of such sessions was possibly sent a relatively long time ago (days, weeks, months). This document introduces the concept of Summaries. It defines a new optional BMP message type, called State Summary, and a new TLV, called Summary Id. A Summary is similar to the initial synchronisation performed upon establishment of the BMP session: all BGP session information is exported in Peer Up Notification messages, and all RIB contents are exported in Route Monitoring messages. All the messages carry the new Summary Id TLV, containing an ID uniquely identifying the summary these messages belong to. The messages are preceded by a State Summary message carrying the same Summary Id TLV, as well as meta-data describing the Summary. "Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration", Weiqiang Cheng, Ruibo Han, Changwang Lin, Yuanxiang Qiu, 2025-05-11, 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 IPv6 stateless address autoconfiguration. "OAuth 2.0 Client ID Scheme", Aaron Parecki, Daniel Fett, Joseph Heenan, 2025-02-07, This specification defines the concept of a Client Identifier Scheme to enable Authorization Servers and Clients to use more than one mechanism to obtain and validate Client metadata. "OpenPGP Signatures and Signed Messages", Andrew Gallagher, 2025-03-17, This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. "Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm", Mohit Tahiliani, 2025-03-03, This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. "Advertise SRv6 Locator Information by IPv6 Neighbor Discovery", Liyan Gong, Changwang Lin, Acee Lindem, 2025-03-03, 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. "Use of Composite ML-DSA in TLS 1.3", Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer, 2025-06-15, Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3. "CAA Security Tag for Cryptographically-Constrained Domain Validation", Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal, 2025-03-21, Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which may be located between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man-in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically- constrained domain validation procedures. "Controlling IP Fragmentation on Common Platforms", Marten Seemann, Max Inden, 2025-03-02, When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. "PSI based on ECDH", wangyuchen, Wenting, Yufei Lu, Cheng Hong, Jin Peng, 2025-02-16, This document describes Elliptic Curve Diffie-Hellman Private Set Intersection (ECDH-PSI) for 2 participants. It instantiates the classical Meadows match-making protocol with standard elliptic curves and hash-to-curve methods, enabling the participants to find common records in a privacy-respecting way. In ECDH-PSI, records are encoded to points on an elliptic curve, and masked by the private keys of both participants. To compute the intersection, a participant only uses the jointly masked datasets and its original dataset locally, which prevents its partner from learning the private records not in the intersection. "Use of SLH-DSA in TLS 1.3", Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer, 2025-04-13, This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. "Open Cloud Mesh", Giuseppe Presti, Michiel de Jong, Mahdi Baghbani, Micke Nordin, 2025-06-13, Open Cloud Mesh 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. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. "Throughput Advice Object for SCONE", Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras, 2025-04-27, Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.). "Scalable Quality Extension for the Opus Codec", Jean-Marc Valin, 2025-03-17, This document updates RFC6716 to add support for a scalable quality layer. "Certificate Status Information Mechanism Description Updates to RFC 5280", Penghui Liu, Yu Fu, Meiling Chen, Xiang Liu, Yu Zhang, 2025-06-04, The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960]. "Problem Statement about IPv6 Support for Multiple Routers, Multiple Interfaces, and Multiple Prefixes", Fernando Gont, 2025-03-03, This document discusses current limitations in IPv6 Stateless Address Auto-configuration (SLAAC) that prevent support for common multi- router, multi-interface, and multi-prefix scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. "DKIM Access Control and Differential Changes", Steffen Nurpmeso, 2025-03-31, This document specifies a bundle of DKIM (RFC 6376) extensions and adjustments. They do not hinder the currently distributed processing environment that includes DKIM, ARC, DMARC, and SPF, and are as such backward compatible. Their aim is however to ultimately slim down the email environment that needs to be administrated and maintained, by establishing mutual agreements in between sender and receiver(s), verifiable through public-key cryptography, and let the SMTP protocol handle decisions solely based upon that. "SCONE Solution Analysis", Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras, 2025-04-27, This document provides an analysis of various SCONE solutions to share the throughput advice. "Technical guidelines of Web server certification path validation for Interent browser", Penghui Liu, Yu Fu, Meiling Chen, Xiang Liu, Yu Zhang, 2025-06-04, In Web PKI, certificate path construction and validation are crucial security review processes. At present, there are many Internet browser manufacturers around the world. With the change of security practices and the development of technology, the certificate validation process in Internet browser industry is relatively messy, including various private implementations of manufacturers. It is a typical patching improvement method, and the implementation of process functions is relatively arbitrary. This document provides a technical guide for certification path validation of web server certificates during Internet SSL/TLS protocol communication for Web PKI, including the basic path verification process, as well as reference procedures, guidance and suggestions for input, initialization, and basic certificate processing in the verification process. This document is applicable to the development and application of Internet browsers, as well as other similar digital certificate authentication systems requiring SSL/TLS security protocol secure communication. "QUIC Path Management for Multi-Path Configurations", Bill Gage, 2025-03-02, This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. "Problem Statement for High Performance Wide Area Networks", Quan Xiong, Kehan Yao, Cancan Huang, Han Zhengxin, Junfeng Zhao, 2025-02-25, High Performance Wide Area Network (HP-WAN) is designed for many applications such as scientific research, academia, education and other data-intensive applications which demand high-speed data transmission over WANs, and it needs to provide efficient transmission services within a completion time. This document outlines the problems for HP-WANs. "EUF-CMA for the Cryptographic Message Syntax (CMS) SignedData", Daniel Van Geest, Falko Strenzke, 2025-03-18, 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 a number of potential mitigations for LAMPS working group discussion. "Cookies: HTTP State Management Mechanism", Anne van Kesteren, Johann Hofmann, 2025-04-17, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. "YANG deVELpment PrOCEss & maintenance (VELOCE)", Mohamed Boucadair, 2025-04-13, This document describes a YANG deVELpment PrOCEss & maintenance (VELOCE) that is more suitable for the development of YANG modules within the IETF. 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/boucadair/draft-boucadair-veloce-yang. "Source Buffer Management", Stuart Cheshire, 2025-03-16, 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. "Fast failure detection in VRRP with S-BFD", Nicola Serafini, 2025-01-27, The Virtual Router Redundancy Protocol (VRRP) protocol depends on the availability of layer three (3) IPvX connectivity between redundant peers and it can interact with the variant of Seamless Bidirectional Forwarding Detection (S-BFD) protocol to achieve a much faster failure detection. This document describes how to extend the VRRP protocol to support S-BFD as a detection system for Primary Router failures. To announce the use of this implementation, a new VRRP packet type and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the S-BFD Discriminators is also implemented. "Post-Quantum Guidance for TLS.", Stephen Farrell, 2024-12-15, We provide guidance on the use of post-quantum algorithms for those deploying applications using TLS. "Security and Privacy Considerations for Deep Space Network", Lei Xu, Cuicui Wang, Yu Fu, Yunshi Wang, 2024-12-16, Deep Space Network (DSN) inherits potential security vulnerabilities as well as privacy issues. This document describes various threats and security concerns related to Deep Space Networks and existing approaches to solve these threats. "What is TCP?", Carsten Bormann, 2024-12-18, This document references STD 7. "Application State Components for More Instant Messaging Interoperability (MIMI)", Rohan Mahy, 2025-02-11, This document presents structures for room metadata, participant lists, pre-authorized roles for future participants, and role-based access control, all of which are intended for use in MIMI (More Instant Messaging Interoperability). "OAuth Resource Helper", Pieter van der Meulen, Michiel de Jong, 2024-12-19, This Internet Draft introduces the concept of a Resource Helper in OAuth 2.0. A Resource Helper is a modular component that assists the Authorization Server in managing fine-grained authorization processes. The Resource Helper, associated with a specific Resource Server, handles scope selection and resource-specific details, providing the user-interface for the Resource Owner to approve or refine access requests. By offloading scope-related user interaction to the Resource Helper, the Authorization Server remains generic and stable while the Resource Helper evolves alongside the Resource Server's requirements. This specification defines the protocol, interfaces, and flow between the Authorization Server and the Resource Helper. Introducing a Resource Helper does not affect the OAuth client or the interaction between the OAuth client and the Resource Server. "A Task Segmentation Framework for Computing-Aware Traffic Steering", Chuanghuan Li, 89 117, Shicong Zhang, Bo Ma, 2024-12-21, This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the stepwise mode, providing detailed workflows for each. "Trust is non-negotiable", Dennis Jackson, 2024-12-20, This document considers proposals to enable the negotiation of trust anchors in TLS. It makes three basic arguments: that trust negotiation is not helpful in addressing the problems it claims to address, that trust negotiation instead comes with material harms to the critical trust infrastructure of the Internet, and that the proposed mechanisms for deploying trust negotiation are unworkable. This draft goes on to discuss simpler and more effective solutions to these problems. "PCRP Webhook Specification", Deepak Arumugham, 2024-12-23, This document defines the PCRP (Ping, Challenge, Resolve, Product) Specification for Webhook events in a standardized way. It is specifically designed to address the challenges faced in current webhook event implementations, which lack consistency and a defined flow. PCRP introduces a new header X-PCRP-Type to indicate the step of the process, and its values include ping, challenge, resolve, and product. "Next Generation browser", pradeep xplorer, 2024-12-27, Next Generation browser "Public Key Hash for Local Domains", Dan Wing, 2024-12-29, This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake. "SRv6 Group Based Policy", Tianpeng Yu, 2025-01-01, This document extends the Segment Routing over IPv6 (SRv6) Network Programming framework [RFC8986] by incorporating group-based policy capabilities. "Enhancing Local-Use Domain Name Resolution within Link-Local Scope", LiangYi Gong, Zhiwei Yan, Man Zhang, Kejun Dong, Chun Long, 2025-01-01, Link-local networks such as home Internet of Things (IoT) and industrial Internet of Things are becoming increasingly prosperous, with a large number of small devices deployed in the link-local networks. These devices discover each other through ".local." domain names of DNS-based zero-configuration network protocol. However, the lack of specialized security operations to supervise link-local DNS resolution leads to some security risks. This memo addresses the potential risks associated with the leakage of link-local DNS traffic to external networks, the lack of identity authentication on ".local." domain requests, and the lack of rate-limiting on ".local." domain responses, which poses the leakage of link-local device information and the risk of DDoS attacks. Furthermore, the document proposes a set of best practices and technical solutions to mitigate these risks and ensure that ".local." domain name resolution remains confined within the local network segment. "Distributed Micro Service Communication architecture based on Content Semantic", Xueting Li, Aijun Wang, Wei Wang, Dirk KUTSCHER, 2025-01-02, This draft introduces a novel communication architecture, called Distributed Micro Service Communication architecture (DMSC). It includes multiple aspects of microservice communication, such as service registration, service discovery, service routing, service scheduling, and more , Which to achieve all the essential functionalities provided by current centralized service networks. By incorporating content-semantic communication, DMSC significantly enhances the performance, scalability, and reliability of microservice communication. It provides a robust architecture for managing the complex communication requirements of distributed microservices, ensuring data integrity, security, and efficient resource utilization. Furthermore, DMSC provides a reference direction for the transition of the service mesh infrastructure from a location-based model to a content- and service-centric paradigm. "Updates to SIPREC correcting Metadata Media Type", Dan Mongrain, 2025-01-06, SIP-based Media Recording (SIPREC) protocol is defined by both RFC 7865 and RFC 7866. Unfortunately both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFCs registered the new media type. This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and registers the new media type. "Problem Statements of Service Mesh Infrastructure and Requirements of DMSC", Enge Song, Yang Song, Shaokai Zhang, Xing Li, Jiangu Zhao, 2025-01-06, Service meshes, as one infrastructure, has been widely used in the major public cloud providers. Its main function is to accomplish the policy routing, precise traffic allocation, and traffic throttling etc. Currently, the design and implementation of service mesh takes the centralized control approach, which bring various challenges for its current deployments and further developments. This document analyzes the problems that exists in current service mesh implementations, and provide the requirements for the future distributed micro service communication(DMSC) infrastructure. "A Referee to Authenticate Servers in Local Domains", Dan Wing, 2025-01-07, Obtaining and maintaining PKI certificates for devices in a local domain network is difficult for both technical and human factors reasons. This document describes an alternative approach to securely identify and authenticate servers in the local domain using a HTTPS- based trust anchor system, called a Referee. The Referee allows bootstrapping a network of devices by trusting only the Referee trust anchor in the local domain. "Current State of the Art for Routing in AI Networks", Jie Dong, Dan Li, Qinru Shi, PengFei Huo, 2025-03-03, This document provides an overview of routing technologies that address the needs of traffic engineering and load balancing, with a focus on fast notification for example in adaptive or perceptive routing. As the scale and complexity of networks grow, these technologies are becoming increasingly important when fault tolerance and rapid convergence are critical. This document explores existing solutions from both the IETF and the broader industry, highlighting their applicability to various use cases, including AI workloads and general services that demand low-latency, fault recovery, and dynamic load distribution across data center networks and inter data center. It also offers suggestions for potential IETF initiatives to further develop and standardize these techniques. "Ascon-AEAD128 for JOSE and COSE", Dmytro Ochkas, Helene Le Bouder, Alexander Pelov, 2025-01-21, This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations with Ascon which received a lot of attention in the area of lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption [asconv1.2-caesar]. After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography [asconv1.2-nist]. This recognition makes it particularly interesting to use Ascon with COSE and JOSE structures. This document does not define any new cryptography, only serializations of existing cryptographic systems described in [NIST.SP.800-232]. "Out-of-order Insensitive Traffic In the Network", Zongpeng Du, 2025-01-08, This document describes a kind of out-of-order insensitive traffic in the transport network, and the related load balancing mechanism for it. "Hybrid Post-quantum Key Exchange SM2-MLKEM for TLSv1.3", Paul Yang, Cong Peng, Jin Hu, Shine Sun, 2025-02-10, This document specifies how to form a hybrid key exchange with CurveSM2 and MLKEM in Transport Layer Security (TLS) protocol version 1.3. Related IETF drafts include [hybrid] and [ecdhe-mlkem]. "A 3D Location Profile for the Location-to-Service Translation (LoST) Protocol", Dan Banks, 2025-01-10, This document defines a new location profile containing three- dimensional (3D) shapes to be used with the Location-to-Service Translation Protocol (LoST) defined in RFC 5222. Registration of the 3D location profile in the "Location-to-Service Translation (LoST) Location Profiles" IANA registry is requested accordingly. Inconsistencies in RFC 5222 relating to additional location profiles are revised and additional clarification is given to assist implementors when using this profile. "Technical Considerations for Distributed Micro Services Communication", Dongyu Yuan, Daniel Huang, Chuanyang Miao, 2025-02-05, With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, updated framework and architecture would be required and designed, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning with Distributed Micro Service Communication (DMSC). "JSON Web Token Best Current Practices", Yaron Sheffer, Dick Hardt, Michael Jones, 2025-05-23, 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 document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. "RADIUS attributes for National Security and Emergency Preparedness Service", Sri Gundavelli, Subir Das, Mark Grayson, Martin Dolly, An Nguyen, 2025-01-15, This document describes RADIUS attributes for supporting authorization of Emergency Preparedness Communication Service (EPCS), enabling authorized users to benefit from preferential access to Wi- Fi network resources during congestion. "Incrementally Deployable DNSSEC Delegation", Philip Homburg, Willem Toorop, 2025-01-16, This document proposes a DNSSEC delegation mechanism that complements [I-D.homburg-deleg-incremental-deleg]. In addition this mechanism simplifies multi-signer setups by removing the need to coordinate for signers during key rollovers. "Media over QUIC - Use Cases", Luke Curley, 2025-01-16, MoQ is designed to serve live tracks over a CDN to viewers with varying latency and quality targets: the entire spectrum between real-time and VOD. However, it's difficult to understand how to use the transport given the layering and complexity of live media delivery. This document outlines how an application could use MoQ to deliver video, audio, and metadata in a variety of scenarios. "Vocabulary for Expressing Content Preferences for AI Training", Thom Vaughan, 2025-01-20, This document proposes a vocabulary for expressing content preferences for rightsholders who wish to manage the use of their content in AI training. This vocabulary allows publishers to express preferences through metadata or content-delivery protocols. The vocabulary can be applied at different levels of granularity and incorporates preferences for permissions, usage scope, and data retention, providing a foundation for interoperability across various Internet protocols. "RPC Roles and Responsibilities", Alexis Rossi, 2025-01-21, This document updates RFC 9280 to specify that the RPC is responsible for operational decisions needed to implement RFC Series policies as they pertain to the document publication process code and tools, and provides a pathway for resolution of disagreements with those operational decisions. This document also updates RFC9280 to acknowledge that RFC Consumers, a distinct but partially overlapping group with IETF participants, must be specifically considered in the process of writing and implementing RFC Series policies, and makes the RPC responsible for representing their interests. Additionally, this document updates language in RFC7990, RFC7991, RFC7992, RFC7993, RFC7994, RFC7995, RFC7996, and RFC7997 to transfer responsibilities previously held by the RFC Editor or RFC Series Editor to the RPC. "Documenting and Referencing Cryptographic Components in IETF Documents", Paul Wouters, Paul Hoffman, 2025-03-03, This document describes the history of how cryptographic components have been documented and referenced in the IETF, such as in RFCs, Internet Drafts, and exernal sources. It also gives guidance for how such specification should happen in the future. %% (To be removed before publication as an RFC) This document is being developed in SAAG. There is a git repo for the document at https://github.com/paulehoffman/draft-paulwh-crypto-components (https://github.com/paulehoffman/draft-paulwh-crypto-components). %% "DNS Account Handles, A Whitepaper", Phillip Hallam-Baker, 2025-02-18, A proposal for use of DNS names to support universal account identifiers 'handles' is described. Once registered, a handle may be used for authentication to any network service, to initiate communication with the holder or as the basis for IoT device management. This document is a whitepaper proposing the general approach. A strawman prototype supporting single account Web login across multiple sites, onboarding of IoT devices and end to end secure messaging, file-drop, voice and video and has been built using existing and proposed IETF work. "AES-GMAC for COSE", Brian Sipos, 2025-01-23, This document registers COSE algorithm code points for using the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a Message Authentication Code (AES-GMAC). The security strength provided by these registrations is identical to existing COSE registrations for AES-GCM authenticated encryption. "Introducing `s://` as a Secure URL Scheme to replace `https://`", Ali Ranalvi, 2025-01-24, This document proposes the introduction of `s://` as a universal shorthand for secure URLs, replacing the explicit use of `https://`. The proposed scheme simplifies URL syntax, assumes secure connections by default, and aligns with the modern web's security-first approach. The adoption of `s://` is expected to enhance user experience, improve efficiency, and reinforce secure practices across the internet. "HTTP Streaming: Standard for Age-Appropriate Video Content Guidelines (VCG) and Delivery", MAGADUM Ashok, 2025-01-24, The delivery of inappropriate video content for OTT and Social Media with HTTP video streaming is a serious worldwide problem. Most of the countries have established age-related and parental guidelines to warn about inappropriate or unintended content, particularly for children. However, these guidelines do not offer the freedom or convenience for audiences to avoid consumption of inappropriate content for their target age group instead just provide warning messages only.The Age-Relevant Video Content Guidelines (VCG) Standard defines a standard meta data format which covers fully and partially scene by scene age relevancy meta data for video and audio content and hence establishes a mechanism for delivering video and audio content tailored to the viewers' age groups. The Video Content Guidelines(VCG) is a meta data file which can enable existing HTTP based adaptive streaming standard like HLS, DASH, CMAF, MSS and HDS with updating manifest file using VCG meta data, that ensures only the target age-appropriate content is delivered to the audience and in-appropriate data can be skipped or modified so that different age group audience can choose what they want to watch. This ensures the compatibility of with the standard adaptive streaming protocols and players, so that the existing social Media and OTT streaming infrastructure continue to work without any major changes. "Use Cases for Energy Efficiency Management", Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos, 2025-05-16, 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 "The IMAP WEBPUSH extension", Simon Gougeon, 2025-03-19, This document defines a WEBPUSH extension of the Internet Message Access Protocol (IMAP) that permits IMAP servers to send WebPush notifications. "Architecture of Content-Based Service Router", Changwang Lin, Wei Wang, Xueting Li, 2025-01-27, This document first describes an architecture of Content-based Service Router (CSR), which is used to exchange service prefixes and topology information based on distributed routing protocol, and optimize routing based on service prefixes and topology, as one important component of Distributed Micro Service Communication (DMSC) architecture. "DNS Update with JSON", Paul Hoffman, 2025-02-24, It is common for service providers such as certificate authorities and social media providers to want users to update the users' zones to prove that they control those zones, or to add other features. Currently, service providers tell users to do this using human language describing the resource record type and data values to enter into the zone. This document describes a text format, called "DNS update with JSON" or "DUJ", for such a service provider to give to a user, with the expectation that the user would copy and paste the text to their DNS operator to update the user's zone. DNS operators who know how to handle DUJ strings will make the update process easier and more predictable for their users. "Video Session Data Rate for SCONE protocol", Dan Druta, Emir Halepovic, Theo Karagioules, 2025-01-30, The SCONE protocol requires a semantically consistent way for CSPs to convey a throughput advice. The Video Session Data Rate (VSDR) describes the formula to be applied both for setting the limit on the CAP side as well as for the CSP to validate conformance with the policy. "Microservice Communication Resource Scheduling for Distributed AI Model", 4875690059616E67, Tiankuo, Qiuyan Yao, Zepeng Zhang, 2025-03-03, This document describes the architecture of microservice communication resource scheduling for distributed AI model. "Scalable Name-Based Packet Forwarding", Tian Song, Tianlong Li, Zhu Ran, Zhang Qianyu, Xia Qianhui, 2025-01-30, This document specifies a scalable approach to name-based packet forwarding, a fundamental component of content semantic network architectures. Unlike IP-based forwarding, name-based forwarding must address the challenges of handling variable-length, unbounded keys and significantly larger namespaces. The proposed approach leverages two key insights to enable scalable forwarding for billions of prefixes. First, by representing names as binary strings, forwarding tables with millions of entries can be effectively compressed using Patricia tries to fit within contemporary line card memory. Second, the data structure is designed and optimized to ensure its size is dependent only on the number of rules, not the length of the rules themselves. "Dynamic Trust Security Architecture for Distributed Service Mesh", Xuan Si, 2025-03-03, This document proposes a dynamic trust security architecture based on Distributed Micro Service Communication (DMSC) to address the security risks in the communication of microservices. The DMSC architecture, by leveraging content semantic routing and decentralized control, transforms the traditional host-centric communication mode into a service-centric paradigm. Although DMSC enhances scalability and flexibility, its distributed nature introduces risks. To cope with these risks, it is necessary to consider security solutions for distributed large-scale microservice communication and ensure the security of services while minimizing the impact on the communication architecture. "SASL Passkey", Ben Bucksch, Stephen Farrell, 2025-01-31, Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey. "IKEv2 Support of ML-DSA", Scott Fluhrer, 2025-01-31, One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. NIST has recently standardized ML-DSA, which is a signature algorithm believed to be secure against Quantum Computers. This document describes how to use ML-DSA with IKEv2 as an auhentication scheme. "Improving Support for Multi-Router, Multi-Interface, and Multi-Prefix Scenarios", Fernando Gont, 2025-03-03, This document specifies a improvements to IPv6 Stateless Address Autoncofiguration (SLAAC) to fully support common multi-router, multi-interface, and multi-prefix scenarios. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8504, RFC 8028, and RFC 6724, such that these scenarios are properly supported by IPv6 host implementations. "Enhanced JWE Security with Detached Additional Authenticated Data (AAD)", Tirumaleswar Reddy.K, Hannes Tschofenig, 2025-03-15, This draft introduces a mechanism to support detached Additional Authenticated Data (AAD) in JWE (JSON Web Encryption), allowing the AAD to be derived from context-specific information, such as session identifiers, algorithm identifiers, and identifiers of communication endpoints, rather than being transmitted in-band. This mechanism strengthens security by mitigating risk against unknown-key-share attacks and/or other exploitation techniques that depend on some type of confusion over the role played by each party. The document explains how to integrate this functionality into JWE, covering both JWE JSON Serialization and JWE Compact Serialization. "GREASE Code Points in OpenPGP", Andrew Gallagher, 2025-02-03, This document reserves code points in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS. "WIMSE Credential Exchange", Arndt Schwenkschuster, 2025-03-03, 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 the Secure Shell (SSH) Protocol", Simon Josefsson, 2025-02-04, This document describes the use of Sphincs+/SLH-DSA digital signatures in the Secure Shell (SSH) protocol. "SCHC Rule Format for Message Aggregation in Delay Tolerant Networks", Alexander Pelov, 2025-03-31, This document defines a new Rule Format for Message Aggregation (referred to as Aggregation) within the SCHC framework. By bundling multiple SCHC-compressed packets into a single Aggregation Data Unit (ADU), the mechanism reduces the number of transmissions required in delay-tolerant networks. The Aggregation process is triggered by conditions such as reaching the L2 Maximum Transmission Unit (MTU), exceeding a maximum delay, or meeting a minimum packet rate threshold. This new rule type is backward compatible with existing SCHC operations and offers an efficient solution for energy-sensitive and asymmetric communication scenarios. "SCHC Reliability Fragmentation", Alexander Pelov, Carles Gomez, 2025-03-31, This document specifies a fragmentation mode used for reliability within the SCHC framework. Building on the fragmentation mechanisms defined in RFC8724, this rule format is tailored to ensure the reliable delivery of small messages that do not trigger conventional fragmentation. A key enhancement is the inclusion of a size field, indicating the total byte-length of the message, and modifications to the state machine to support a persistent session with wrap-around windows. Two operational modes are defined: * RelNoAck: A mode derived from SCHC No-Ack fragmentation, where fragments are transmitted without expecting per-fragment acknowledgments. Losses are tolerated within a configured threshold. * RelAckOnErr: A mode derived from SCHC Ack-On-Error fragmentation, where the receiver actively monitors for missing fragments and initiates recovery through explicit negative acknowledgments. These modes offer operators the flexibility to balance recovery overhead against latency and reliability requirements in constrained network environments. "SCHC Architecture for Process Stacking and Routing in Constrained Networks", Alexander Pelov, 2025-02-04, This document specifies architectural guidelines for dynamically stacking and routing SCHC processes in constrained networks. It details how independent SCHC modules can be composed into processing chains that adapt to PDU attributes. For instance, SCHC Compression may trigger SCHC Fragmentation when the compressed PDU exceeds the L2 MTU, or alternatively, trigger SCHC Aggregation. For traffic that is not delay tolerant, a direct routing from SCHC Compression to SCHC Reliability Fragmentation is provided. Subsequent processing by SCHC FEC Fragmentation modules ensures robust error correction. This modular approach promotes scalability and flexibility within the SCHC framework. "A comparative analysis of SCONE relative to TRAIN", Martin Thomson, 2025-02-04, A merge of the rate availability signaling schemes in the SCONE and TRAIN proposals is analysed and found to be infeasible. "Lightweight Directory Access Protocol (LDAP): Additional Syntaxes", Carl Codere, 2025-02-04, This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes. "rLEDBAT for QUIC", Marcelo Bagnulo, 2025-02-05, This document specifies rLEDBAT for QUIC, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for QUIC at the receiver end. This draft explores adaptation strategies for integrating rLEDBAT with QUIC's framework, aiming to maintain compatibility with QUIC. "Anonymous Rate-Limited Credentials", Cathie Yun, Christopher Wood, 2025-02-05, 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. "Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials", Cathie Yun, Christopher Wood, 2025-02-05, This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. "Distributed DNSSEC Multi-Signer Bootstrap", Leon Fernandez, Erik Bergstrom, Johan Stenstam, Steve Crocker, 2025-02-07, This document presents an architecture for a distributed DNSSEC multi-signer model that most closely resembles "model 2" in [RFC8901]. It defines two multi-signer specific entities: the "multi-signer agent" (MSA) that is responsible for the multi-signer process and the "combiner", which is responsible for "combining" unsigned zone data from the zone owner with zone data under control of the MSA. It introduces a new DNS RRtype, HSYNC, that is used by the zone owner to designate the chosen DNS Providers (signing and/or serving the zone). Furthermore it describes a mechanism for the MSAs to establish secure communication with each other, either via “pure DNS” communication secured by DNS SIG(0) signatures on each message or via a RESTful API secured by TLS. Finally, the document describes two models for multi-signer process synchronization: “leader/follower mode” and “peer mode” and the mechanism by which a set of MSAs decide which model to use for a given zone. The scope of the document is only the distributed aspect of DNSSEC multi-signer up to the point where secure communication and synchronization method between MSAs has been established. The “multi-signer algorithms” that deal with the actual synchronization required for multi-signer operation are described in [I-D.draft-ietf-dnsop-dnssec-automation]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer (https://github.com/johanix/draft-leon-dnsop-distributed-multi- signer). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. "Lightweight Secure Shell (SSH) Signature Format", Sebastian Kinne, Damien Miller, Simon Josefsson, 2025-04-24, This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. "Hypertext Command Line Interface", Jeff Michaud, 2025-02-08, This document proposes a codification of resources and their relations with hyperlinks, using Unix-like command line interface (CLI) semantics, to foster the creation of a reusable and prolific intersection between the REST architectural style and the pipe and filter style. "SDP Offer/Answer for RTP over QUIC (RoQ)", Spencer Dawkins, Victor Avila, 2025-02-10, This 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 as a transport protocol. These new values are necessary 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. This document also contains non-normative guidance for implementers. "A Method for Generating Semantically Opaque IPv6 Interface Identifiers (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Fernando Gont, 2025-02-10, This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration (SLAAC). "Bidirectional Metric based Shortest Path First Mechanism", Aijun Wang, 2025-02-10, This document describes the mechanism that can be used to accomplish the Shortest Path First(SPF) calculation within network based on the bidirectional metrics of the links. "User Attributes in OpenPGP", Andrew Gallagher, 2025-02-11, This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. "Privacy Pass Reverse Flow", Thibault Meunier, 2025-02-11, This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a reverse flow from the Origin to the Client/Attester/Issuer. It describes a way for redeeming Origins to perform new issuances in the same request. "Recommendations for Key Directories over HTTP", Fisher Darling, Thibault Meunier, Simon Newton, 2025-02-13, This document defines recommendations for protocols that expose public keys over HTTP. "IMAP REMEMBERME extension for quick reauthentication token generation", Alexey Melnikov, 2025-02-14, This document specifies an IMAP extension for generating quick reauthentication tokens that allow clients to re-login without user interaction, once authentication using a strong SASL mechanism is completed. "The Multicast Application Port", Nathan Karstens, Stuart Cheshire, Mike McBride, 2025-04-08, This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. "Short Usage Preference Strings for Automated Processing", Martin Thomson, 2025-02-16, Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines a very simple format for expressions. This document updates RFC 9309 to define one means of conveyance. An HTTP header field is also defined. "Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol", Huanxing Zhu, 2025-04-15, 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. "IETF Meeting Network Recommendations", Jason Livingood, 2025-02-23, IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion. "Content Steering", Roger Pantos, Eryk Vershen, 2025-02-17, This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. "Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF", Wei Wang, Aijun Wang, 2025-02-17, This draft proposes a new intra-domain Source Address Validation (SAV) solution. This solution leverages the Bidirectional Metric- based Shortest Path First (BM-SPF) mechanism to avoid the complexity introduced by asymmetric routing for source address validation. It allows intra-domain routers to generate directly the SAV rule from the router's FIB table, based on the reality that the source and destination interface will be same if the IGP domain is symmetric assured. "Export of SRv6 Path Segment Identifier Information in IPFIX", Yao Liu, Zhenqiang Li, Yisong Liu, Changwang Lin, 2025-05-26, This document introduces a new IPFIX Information Element to identify the Path Segment Identifier(PSID) in the SRH for SRv6 path identification purpose. "Dynamic Overlay Load Balancing", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Ali Sajassi, Changwang Lin, 2025-02-18, 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. "COSE Algorithms for Two-Party Signing", Emil Lundberg, Michael Jones, 2025-03-03, This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited- bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data. "Synchronized Video-on-Demand (VoD) Viewing with Media over QUIC Transport", Ahmet Pehlivanoglu, Kerem Bekmez, Basar Yumakogullari, Zafer Gurel, Ali Begen, 2025-02-18, This draft presents an approach for synchronized video-on-demand (VoD) viewing with Media over QUIC Transport (MOQT). It extends the current MOQT protocol to enable synchronized VoD functionality. This approach adapts MOQ’s push-content architecture to include interactive features such as pause, resume and seek. "In Situ Operations, Administration, and Maintenance (IOAM) Active Measurement for Multi-path", Li Zhang, Tianran Zhou, Junfeng Ma, 2025-02-18, 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. "A Profile for Forwarding Commitments (FCs)", Yangfei Guo, Xiaoliang Wang, Ke Xu, Zhuotao liu, Li Qi, 2025-02-18, This document defines a Cryptographic Message Syntax (CMS) protected content type for Forwarding Commitments (FCs) objects used in Resource Public Key Infrastructure (RPKI). An FC is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an FC's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. "BGP AS_PATH Verification Based on Forwarding Commitment (FC) Objects", Ke Xu, Shenglin Jiang, Yangfei Guo, Xiaoliang Wang, 2025-02-18, The Forwarding Commitment (FC) is an RPKI object that attests to the complete routing intents description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an FC-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that FC can help address and provides operational considerations associated with FC deployment. "Bitwise IP Filters for BGP FlowSpec", Nat Kao, 2025-02-19, This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. "QUIC Profile for Deep Space", Marc Blanchet, 2025-02-19, Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. In this context, typical QUIC stacks default transport parameters for terrestrial Internet are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case and guidance to QUIC stack developers to properly expose the required transport parameters in their API. "Forward and Reverse HTTP/3 over WebTransport", Benjamin Schwartz, Yaroslav Rosomakho, 2025-02-19, HTTP/3 was initially specified only for use with the QUIC version 1 transport protocol. This specification defines how to use HTTP/3 over a WebTransport session, which can be implemented using any WebTransport protocol. This enables operation of HTTP/3 when UDP based transport is not available, as well as server-initiated HTTP/3 requests. "Standardized Query Name for DNS Resolver Reachability Probes", Benjamin Schwartz, Puneet Sood, John Todd, 2025-02-19, This specification standardizes DNS names that should be used for checking connectivity to a DNS server. 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-sst-dnsop-probe-name/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/probe-name. "Anomalous Packets Handling for DetNet", Han Zhengxin, Ran Pang, Chang Liu, Jinjie Yan, Xiangyang Zhu, 2025-02-19, In deterministic networking (DetNet), there may be resource conflicts at the flow aggregation nodes, resulting in network anomalies. The existing mechanisms for handling anomalous packets in the data plane are crude, such as discarding or processing them as BE flows, so the network performance may be worse than applying traditional QoS. Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an anomalous packet handling solution for anomalous traffic in DetNet. This solution includes two policies: the packet squeezing policy and the packet degrading policy, which can be applied flexibly to a variety of queuing mechanisms, thereby ensuring that network traffic for deterministic services is preferentially scheduled in anomalous situations. "High Performance Wide Area Network (HPWAN) Use Cases and Requirements -- From Public Operator's View", Kehan Yao, Quan Xiong, 2025-02-20, Bulk data transfer is a long-lived service over the past twenty years. High Performance Wide Area Networks (HP-WANs) are the backbone of global network infrastructure, enabling the seamless transfer of vast amounts of data and supporting advanced scientific collaborations worldwide. Many of the state-of-the-art dedicated networks have been mentioned in [I-D.kcrh-hpwan-state-of-art]. For non-dedicated networks like public operator's network, the case is different in terms of QoS policies, security policies, etc. This document presents use cases and requirements of HPWAN from public operator's view. "Use of Variable-Length Output Preudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2025-04-08, This document specifies the use of variable-length output Preudo- 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 Preudo-Random Functions are used in IKEv2 and its extensions. "Advertisement of SR Policy Administative Flags using BGP Link-State", Changwang Lin, Jinming Li, Ran Chen, 2025-02-20, This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. "IPv6 Checksum Option", Tom Herbert, 2025-02-20, This document specifies a Checksum Option for IPv6. This is a Destination Option that allows a checksum to be computed over a variable number of bytes in the packet. The option allows the ICMPv6 checksum to be optional, and the UDPv6 checksum to be generally optional. "Date and Time on the Internet: Durations", Joe Tsai, 2025-02-20, This document specifies a syntax for representing time durations; the syntax is a subset of that specified by ISO 8601. "QUIC network awareness Acknowledgements", Gao xing, Mengyao Han, Zheng Ruan, Hang Shi, 2025-02-21, This document defines a quic ACK frame format for notifying network status information. "Registry scoped members for RPSL set objects", Sasha Romijn, James Bensley, 2025-02-21, This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility. "Export of QUIC Information in IP Flow Information Export (IPFIX)", Changwang Lin, Yisong Liu, Yao Liu, 2025-02-28, This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information which contained QUIC Header, QUIC Frame and Stream that traffic is being forwarded with. "Updates to SMTP related IANA registries", Alexey Melnikov, 2025-05-13, 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. "Eligibility Concept in Segment Routing Policies", Amal Karboubi, Himanshu Shah, Siva Sivabalan, Andrew Stone, Christian Schmutzer, 2025-02-28, Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. "Lightweight Authentication Methods for IP Header", Linda Dunbar, Kausik Majumdar, Scott Fluhrer, 2025-02-21, This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. "IP in Deep Space: Key Characteristics, Use Cases and Requirements", Marc Blanchet, Wesley Eddy, Marshall Eubanks, 2025-03-18, Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. "Critical-CH for Client Hint Reliability", Victor Tan, 2025-02-21, This document defines the Critical-CH HTTP response header to allow HTTP servers to reliably specify their Client Hint preferences. 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/Tanych/http-client-hint-reliability. "Client Hint Reliability ACCEPT_CH Frame", Victor Tan, 2025-02-21, This document defines the ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably specify their Client Hint preferences. It aims to improve the performance to deliver Client Hint. 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/Tanych/http-client-hint-reliability. "Flooding Reduction Algorithms Framework", Tony Przygienda, Shraddha Hegde, 2025-04-25, This document introduces a framework to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. "RPKI Relying Party with Distributed Systems of Synchronization Nodes", Di Ma, Yanbiao Li, Yu Zhang, Shicong Zhang, 2025-02-22, This document describes a current practice of establishing an RPKI relying party with distributed systems of synchronization nodes. "Improvements to the One-Time Password System defined by RFC2289", Regis Corbel, 2025-02-22, This document aims to submit a few improvements to the RFC2289, which describes a One-Time Password System : interfaces to Secure Hash Algorithms, folding hashes to 64 bits, alternate dictionaries and automatic renewal of authentication parameters will be studied in detail. "Compact DNSSEC", Pan Lanlan, 2025-02-23, This document describes about a compact DNSSEC scheme for resource- limited second-level domain (SLD), which is focused on NS RR. "Authenticated subdomain whitelist (ASDWL) for second-level domain (SLD)", Pan Lanlan, 2025-02-23, This document describes about an authenticated subdomain whitelist (ASDWL) scheme to mitigate the random subdomain attacks on second- level domain (SLD). "Extended Key Update for QUIC", Yaroslav Rosomakho, Hannes Tschofenig, 2025-02-23, This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. "YANG Data Model for Energy Measurements in Streaming Devices", Dom Robinson, Benjamin Schwarz, Christoph Neumann, 2025-02-24, This document defines a YANG data model for representing energy measurements from streaming-capable devices. The model supports both instantaneous power readings and correlated streaming metrics needed to analyze energy efficiency in streaming applications. "Procedures for Handling Liaison Statements to and from the IETF", Mirja Kuehlewind, Suresh Krishnan, Qin WU, 2025-06-13, 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. "IAB Processes for Management of IETF Liaison Relationships", Suresh Krishnan, Mirja Kuehlewind, Qin WU, 2025-06-14, 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. "Caller ID Verification In Heterogeneous Telecommunication Networks", Feng Hao, Basil Thomas, Steve Smith, Muhammad Azad, 2025-05-31, This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. "Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF", Li Zhang, Jie Dong, 2025-03-03, 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. "Secure DNS RR Update for ACME DNS Based Challenges", Li Ruochen, Haiguang Wang, Zander Lei, 2025-02-25, This document outlines how ACME DNS based challenges can be performed via DNS dynamic updates. 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-li-acme-dns-update/. Discussion of this document takes place on the WG Working Group mailing list (mailto:acme@ietf.org), which is archived at https://datatracker.ietf.org/wg/acme/about/. Subscribe at https://www.ietf.org/mailman/listinfo/acme/. "Unsolved Challenges of IS-IS MP-TLV Proposal", Aijun Wang, 2025-04-28, The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows only for 255 octets of value in maximum. MP-TLV [I-D.ietf-lsr-multi-tlv] gives one proposal trying to solve this issue, but has some unsolved challenges for its implementations and deployment. This document analyzes in detail these challenges and proposes the community to find other better solution. "Bundle Transfer Protocol - Unidirectional", Rick Taylor, 2025-03-31, This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of bundles of different priority, preventing head-of-line blocking impacting performance. The binary wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. "Trustworthy Routing Discovery", Xiaoyong Li, Xinghai Wei, 2025-02-25, End users with high security and privacy requirements expect their data to be transmitted only through trusted devices to mitigate the risk of data leakage. Therefore, the development of trustworthy routing mechanisms is anticipated to be a key trend in the future evolution of the internet. This specification describes a network architecture that supports trustworthy routing and a scheme for carrying trustworthy routing information (TRI) using the BGP and BGPsec protocols. "the service model of NASR", Meiling Chen, Li Su, 2025-02-25, This document describes the service model of Network Attestation for Secure foRwarding (NASR). It lists security capabilities and characteristics of connectivity services that operators can offer and clients can choose from. "Improvement of Congestion Control Methods Based on Bandwidth Measurement", Guangyu Zhao, Zongpeng Du, 2025-02-25, This document discusses how the Congestion Control algorithm integrates and utilizes the bandwidth, rate recommendations, and constraints etc. provided by bandwith measurement to achieve better congestion control.This document discusses how the Congestion Control algorithm. "Sigma Protocols", Michele Orru, 2025-02-25, This document describes Sigma protocols, a secure, general-purpose non-interactive zero-knowledge proof of knowledge. Concretely, the scheme allows proving knowledge of a witness, without revealing any information about the undisclosed messages or the signature itself, while at the same time, guarantying soundness of the overall protocols. "Implicit ECH Configuration for TLS 1.3", Nick Sullivan, 2025-02-25, This document updates the TLS Encrypted ClientHello (ECH) specification [ECH-DRAFT] to support an implicit mode in ECH signaled by a new implicit_ech extension in ECHConfigContents. Clients that detect this extension override certain base ECH rules: * They MAY choose any outer SNI instead of public_name. * They MAY choose any value for the config_id without an application profile or being externally configured. * They MAY use another value than ECHConfig.contents.public_name in the "server_name" extension (rather than they SHOULD use it) Client-facing servers that include implicit_ech in the ECHConfig MUST accommodate flexible config_id usage as defined in Section 10.4. of [ECH-DRAFT]. This approach enables the removal of stable identifiers (fixed config ID and known public_name) that on-path adversaries can use to fingerprint a connection. This improves upon the "Do Not Stick Out" design goal from Section 10.10.4 of [ECH-DRAFT] by allowing clients to choose unpredictable identifiers on the wire in the scenario where the set of ECH configurations the client encounters is small and therefore popular public_name or config_id values "stick out". Note that this increases CPU usage in multi-key deployments because client-facing servers must perform uniform trial decryption to handle arbitrary config_id values. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/grittygrease/draft-sullivan-tls-implicit-ech. "Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism", Ke Xu, Xuewei Feng, Ao Wang, 2025-02-26, As well as the Internet Control Message Protocol for IPv4 (ICMPv4), the Internet Control Message Protocol for IPv6 (ICMPv6) is significant for network diagnostics and error reporting. However, like ICMPv4, ICMPv6 is also vulnerable to off-path forgery, making it difficult for the receiver to verify the legitimacy of a received ICMPv6 error message, particularly when the message contains stateless protocol data (e.g., the message includes a UDP/ICMPv6 packet). Consequently, adversaries on the Internet can forge ICMPv6 error messages carrying stateless protocol data, leading the receiver to erroneously accept the forged message and respond to it. This document proposes enhancement to ICMPv6 by introducing a challenge- confirm mechanism that leverages random numbers embedded in the IPv6 Extension Headers. The enhancement aims to strengthen the authentication of ICMPv6 error messages, thereby mitigating the risks associated with forged messages and improving the overall robustness of the protocol. "Knowledge Graph Construction from Network Data Sources", Ignacio Martinez-Casanueva, Lucia Rodriguez, Pedro Martinez-Julia, 2025-02-26, This document discusses the mechanisms that support the management and creation of knowledge graphs from data sources specific to the network management domain. The document provides background on core aspects such as ontology development, identifies methodologies and standards, and shares guidelines for integrating network data sources. "Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism", Ke Xu, Xuewei Feng, Yuxiang Yang, Li Qi, 2025-02-26, The Internet Control Message Protocol (ICMP) plays a crucial role in network diagnostics and error reporting. However, it is a challenge to verify the legitimacy of a received ICMP error message, particularly when the ICMP error message is embedded with stateless protocol data. As a result, adversaries can forge ICMP error messages, leading to potential exploitation and off-path attacks. This document proposes a novel method to enhance ICMP authentication by introducing a challenge-confirm mechanism. This mechanism embeds random numbers in the IP options field to strengthen the authentication of ICMP error messages. By doing so, it mitigates the risks associated with forged messages, improves the overall robustness of the protocol, and enhances network security. The proposed solution includes details on the challenge-confirm mechanism, random number generation and management, and integration with IP options. Additionally, it discusses security and deployment considerations to ensure its practical implementation. "Support for BMP RIB Purge Notification", Tarek Saad, Narasimha Prasad, 2025-02-26, This document describes a mechanism to notify a BMP collector of the need to purge the state associated with a RIB view of a specific peer. This is useful, for example, when the BMP sender decides to stop exporting a specific RIB view after providing an initial export. The BMP collector can use the per-peer Purge message to take appropriate action to remove the stale state and avoid holding on to irrelevant network data. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Zhaohui Zhang, Mankamana Mishra, 2025-02-26, RFC 6514 describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. This document updates and obsoletes RFC 6514. The original authors of RFC 6514 are listed at the end of this document. "Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks", Chenhao Ma, Chongfeng Xie, 2025-02-26, This document describes the approach of gradually deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also discusses the challenges and potential solutions. "Integrated Sensing and Communications (ISAC) use case for GREEN", Carlos Bernardos, Muhammad Jadoon, Alain Mourad, 2025-02-27, Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents a use case related to ISAC, aiming to facilitate discussions within the GREEN Working Group on the potential benefits, challenges, and requirements. The use case follows a structured template that we propose for all GREEN use cases, ensuring consistency and comparability across different scenarios. "Integrated Sensing and Communications (ISAC) use case for CATS", Carlos Bernardos, Alain Mourad, 2025-02-27, Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents a use case related to ISAC, aiming to facilitate discussions within the CATS Working Group on the potential challenges, and requirements. The aim for this document is to facilitate discussion in the CATS WG for potential consideration of the use case. "Clarifying SRv6 SID List Processing", Adrian Farrel, Suresh Krishnan, 2025-03-30, Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. Segments are indicated by Segment Identifiers (SIDs). SRv6 utilizes the Segment Routing Header (SRH), an IPv6 extension header, that includes a SID list indicating the sequence of segments and any additional processing to be performed. This document updates RFC 8754 by clarifying the processing of SID list entries. It does not change any elements of the SRv6 architecture. "Deferred Key Binding for OAuth", Justin Richer, Brian Campbell, Dean Saxe, 2025-02-27, Sometimes you want to get a token that's tied to a public key but you can't prove possession of that public key. That's when you need to trust me, bruh. "Requirements for Monitoring RPKI-Related Processes on Routers Using BMP", Shuhe Wang, Mingwei Xu, Yangyang Wang, Jia Zhang, 2025-02-27, This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers, including data retrieval from RPKI caches, policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize RPKI monitoring within BMP, addressing scalability and interoperability limitations in existing implementations. "QUIC Multimedia Performance", Christian Huitema, Suhas Nandakumar, 2025-02-27, The QUIC multimedia performance protocol (QPERFM) updates the QUIC performance protocol (QPERF). QPERF provides a simple, general- purpose protocol for testing the performance characteristics of a QUIC implementation. QPERFM updates that protocol to simulate the traffic of multimedia application and measure performance in a multi- media oriented way. 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-huitema-moq-qperfm/. "Non-work Conserving Stateless Core Fair Queuing", Yeoncheol Ryoo, Jinoo Joung, 2025-02-27, 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-02]. 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. "xml2rfc svg limitations", Kesara Rathnayake, 2025-02-27, This is a draft explores limits of SVG artwork in xml2rfc. "Privacy Pass with Token Binding Extension", Wei Guo, Yong Li, Ji Li, Liang Xia, 2025-02-28, This document provides a token binding extension for the Privacy Pass protocol. This extension allows a Client to cryptographically bind a Privacy Pass token to its own generated one-time public key during the issuance flow, without exposing the public key to the Issuer. Later, when spending the token during the redemption flow, the Client must use the corresponding private key to generate a binding proof that the Origin needs to additionally verify except the token itself, where the proof generation can optionally support channel binding. This proof constrains the legitimate presenter of the token to be only the Client who holds the private key and further constrains the legitimate usage of the token to be only the Client's specific channel when channel binding is used in the proof generation, and thus can prevent token export and replay attacks. In addition, the token binding extension does not introduce additional cryptographic primitives, and only uses the primitives currently utilized in the issuance protocol to generate the one-time public-private keypair as well as generate and verify the binding proof. "A Generic Framework for Building Dynamic Decentralized Systems (GFDS)", Diogo Jesus, Joao Leitao, 2025-02-28, Building and managing highly dynamic and heterogeneous decentralized systems can prove to be quite challenging due to the great complexity and scale of such environments. This document specifies a Generic Framework for Building Dynamic Decentralized Systems (GFDS), which composes a reference architecture and execution model for developing and managing these systems, while providing high-level abstractions to users. "LISP Multicast Deployment Experience", Vengada Govindan, Marcin Hamroz, Jaroslaw Gawron, 2025-04-02, 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. "Service Binding Mapping for Service Levels", Gautam Akiwate, Tommy Pauly, 2025-02-28, This document defines a new SvcParamKey for use in Service Binding (SVCB) and HTTPS DNS resource records which enables authoritative DNS servers to indicate that a service should be used by clients having specific service levels or use types, such as "interactive", "background" or "realtime". By providing this information, clients can make informed decisions about which service endpoints to use based on specific applications needs at that time of making connections. "Use SVCB with DNS Service Discovery", Gautam Akiwate, Tommy Pauly, 2025-02-28, DNS Service Discovery (DNS-SD) relies on a sequence of steps to enable the discovery and connection to local network services. The use of Service Binding (SVCB) resource records during the service discovery process enables service instances to advertise properties such as Application-Layer Protocol Negotiation (ALPN) identifiers and other endpoint configuration options. This document describes the use of SVCB / HTTPS RRs in the DNS Service Discovery process as an additional step to allow clients to connect to service instances optimally. "FEC Extension for QUIC", Zheng Huanhuan, Yanmei Liu, 2025-03-01, This document specifies a Forward Error Correction (FEC) extension for the QUIC protocol, which provide protection against packet loss. "Domain Name System in Mostly Isolated Networks", Marc Blanchet, 2025-03-01, This document lists operational methods to enable local DNS name resolving on an isolated network, where that network have intermittent reachability to Internet and/or have very long delays, such as deep space networks, disabling the real-time query and response flow to the authoritative name servers on Internet. "Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization", Zafar Ali, Changwang Lin, Yisong Liu, Ran Chen, Cheng Li, 2025-03-16, 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 a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. "SRv6 Policy SID List Optimization Advertisement", Zafar Ali, Changwang Lin, Yisong Liu, Ran Chen, Cheng Li, Rajesh Venkateswaran, Yuanxiang Qiu, 2025-03-01, 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 a BGP-LS extension to indicate whether the endpoint's node SID is included or excluded in installing SID list(s) of the Candidate Path (CP) of an SRv6 policy. "An Architecture for IP in Deep Space", Marc Blanchet, Wesley Eddy, Tony Li, 2025-03-01, Deep space communications involve long delays (e.g., Earth to Mars is 4-24 minutes) and intermittent communications, because of orbital dynamics. The IP protocol stack used on Earth's Internet is based on assumptions of shorter delays and mostly uninterrupted communications. This document describes the architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configuration and application protocol timers. This architecture applies to the Moon, Mars, or general interplanetary networking. "Mobility Management and Capability Negotiation", Zhiwei Yan, Tianji Jiang, Jianfeng Guan, Tao Huang, Jong-Hyouk Lee, 2025-03-01, Based on different requirements, multiple mobility management protocols have been developed. Different protocols have different functional requirements on the network element or the host and then a scheme should be used in order to support the negotiation and selection of adopted mobility management protocol when a host accesses to a new network. In this draft, this issue is analyzed. "PQC migration use cases for the telecom network", Lun Li, Fei Liu, 2025-03-01, Telecommunications (Telecom) networks are important infrastructure. 3rd Generation Partnership Project (3GPP) provides security specifications for telecom networks, including network devices and user terminals. Meanwhile, the security protocols from IETF widely used in telecom systems. In the docuemnt, we present some post- quantum risks and assessments that exist in current telecom network based on the sepcifiction. From the perspective of RFC, this document analyzes possible post-quantum migration cases and potential strategy in typical telecom network scenarios. The strategy includes the suggestion of related IETF protocols and profiles, which can also provide guidance for other similar communication systems. "PQC Escape Message for Dynamic Migration", Lun Li, Fei Liu, 2025-03-01, In this contribution, a design of escape message mechanism is proposed, where the service provider sends an escape message to the service consumer using existing non-PQC connection and then starts to re-establish the quantum-safe protocol. The proposed escape message can potentially be used in a variety of protocols, including IPsec, TLS, or between the air interface of a cellpohone and a network device. We believe that for largely deployed networks and entities, escape messages can be provided as a plan B for legacy devices of the service provider and consumer that may not able to complete post- quantum migration in advance. It can mitigate negative migration impacts when potential Q-day occurs. "A profile for FC path attribute", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, Yangfei Guo, Jinsi Wu, 2025-03-02, This document specifies a mechanism for embedding a new path attribute, known as the FC path attribute, into BGP UPDATE messages. The FC (Forwarding Commitment) is a cryptographically signed object to certify an AS's routing intent on its directly connected hops. By incorporating the FC path attribute into BGP UPDATE messages, this mechanism provides enhanced route authenticity and lays the groundwork for improved data-plane forwarding verification. This mechanism is backward compatible, which means a router that supports the attribute can interoperate with a router that doesn't, allowing partial deployment across the Internet. "Messaging Layer Security credentials using Selective Disclosure CBOR Web Tokens", Rohan Mahy, 2025-03-02, 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. "Amendments to Stateful PCE Communication Protocol (PCEP)", Andrew Stone, Mike Koldychev, Siva Sivabalan, Diego Achaval, Shuping Peng, Hari Kotni, Samuel Sidor, 2025-03-28, This document updates RFC8231 and RFC8664 to reflect operationalized implementations and define optimizations in the PCEP protocol. "Yang Templates", Robert Wills, 2025-03-02, Yang Templates is a way to more easily manage a network device's configuration when parts of that configuration are repetitive. This document provides a high-level description of Yang Templates, and is expected to evolve into a full solution in later versions. "A Use Case for SCONE Implementation", Sanjay Mishra, Anoop Tomar, Khurram Abbas, Zaheduzzaman Sarker, 2025-04-09, This document describes 3GPP network elements that are capable of rate-limiting a UDP 4-tuple to communicate an upper bound on achievable bitrate termed "throughput advice" to implement SCONE protocol. "Power and Energy Efficiency", Jan Lindblad, Snezana Mitrovic, Marisol Amador, Gonzalo Salgueiro, 2025-03-03, This document specifies a device YANG "dashboard" data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in the form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else. "A Common YANG Data Model for Energy Efficiency Network Management", Qiufang Ma, Qin WU, Emile Stephan, Oscar de Dios, Carlos Pignataro, Sai Han, 2025-03-02, This document defines a common YANG module that is meant to be reused by various energy efficiency-related modules such as energy saving Network models, energy saving network inventory model and energy saving device models. "A Network Inventory Data Model for Energy Efficiency Management", Gen Chen, Qin WU, Emile Stephan, Oscar de Dios, Carlos Pignataro, Sai Han, 2025-03-02, As a complement to the YANG Network Topology Data Model for Energy Efficiency Management, which is used for monitoring the dynamic energy consumption of network devices, this document defines YANG Network Inventory Data Model for Energy Efficiency Management that can be used for maintaining capability related energy efficiency attributes. The model provides both network view and device view of energy efficiency related inventory information. "A Network Topology Data Model for Energy Efficiency Management", Gen Chen, Qin WU, Emile Stephan, Oscar de Dios, Carlos Pignataro, Sai Han, 2025-03-02, This document defines a YANG Network Topology Data Model that can be used for Energy Efficiency Management within a network. The model provides both network-centric view of energy consumption of network devices and device view of energy consumption of individual components within network devices. "Credit-based Flow Control for Cross-AIDC WAN transmission Based on RSVP", Jiayuan Hu, 2025-03-02, This draft defines the Credit-based flow control mechanism for WAN based on the RSVP protocol. With the increasing demand for AI computing power, the computing power of a single AIDC can no longer meet the needs of large model training. This has given rise to cross-AIDC distributed model training, driving the demand for transmitting RoCEv2 packets over WAN networks. AI training is extremely sensitive to network packet loss, and even a small amount of packet loss may lead to a significant decline in training efficiency. In addition, the elephant flow and extreme concurrent traffic also place higher demands on network performance. Credit- based flow control is a Backpressure-based traffic management technology, which has high reliability and stability in practical applications. It can provide high-throughput and zero-packet-loss transmission guarantees for RoCEv2 traffic, effectively ensuring the efficiency of cross-data center AI training. This draft focuses on the scenario where RoCEv2 packets are transmitted through SRv6 tunnels in the WAN and further expands the capabilities of the RSVP protocol in WAN. This draft introduces the Credit-based flow control mechanism into the RSVP protocol to achieve precise traffic control and provides processing analysis. "RPKI Terminology", Zhiwei Yan, Tim Bruijnzeels, Tom Harrison, 2025-03-03, The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times beinconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. "Zero Trust Network Access DM for Network Cloud Interface", Linda Dunbar, dr CHIHI, 2025-03-02, This document defines a YANG data model for implementing Zero Trust Network Access (ZTNA) principles at the network-cloud interface. It addresses security gaps in traditional network architectures by enforcing identity-based access control, least privilege enforcement, secure exposure of resources, and continuous monitoring. The model enables real-time policy enforcement between Cloud-Aware Service Orchestrators and Network Controllers, ensuring that only authorized entities have access to specific network and cloud telemetry. "Fast congestion notification for distributed RoCEv2 network based on SRv6", Zehua Hu, Yongqing Zhu, Xuesong Geng, Jiayuan Hu, Tanxin Pi, 2025-03-02, AI services (e.g. distributed model training, separated storage and model training) drive the need to transmit RMDA packets through SRv6 tunnels in WAN. RoCEv2 is the most popular open standard for achieving RDMA and network offloads over ethernet, with its congestion control based on the combination of PFC and ECN. The document defines the fast congestion notification for distributed RoCEv2 network based on SRv6 tunnels, and further extends PFC and ECN to achieve precise flow control and end-to-end congestion control. "SRv6 Path Verification", Feng Yang, Xiaoqiu Zhang, Changwang Lin, 2025-03-02, This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specificed by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. And this approach also significantly reduces the processing overhead associated with hop- by-hop path verification. "ML-KEM and Hybrid Cipher Suites for Messaging Layer Security", Rohan Mahy, Richard Barnes, 2025-03-02, This document reigsters new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. "PCE SR Policy Extensions for Path Scheduling", Li Zhang, Jie Dong, Tianran Zhou, 2025-03-02, 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. "Routing in Satellite Networks: Challenges & Considerations", Peng Liu, Tianji Jiang, 2025-03-02, The SDO 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on the satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves the significant work to be explored in the IETF domain. This draft stems from the 3GPP satellite use cases that have been studied for many years up to now, across a couple of releases, and lands on summarizing the challenges & considerations of the satellite-based routing. Based on some unique & advantageous characteristics associated with satellite networks, the draft raises briefly the general routing considerations for the integrated Non- Terrestrial & Terrestial Networks. "Framework for High Performance Wide Area Network (HP-WAN)", Quan Xiong, Daniel Huang, Kehan Yao, Changwang Lin, 2025-06-09, This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time 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. "Lightweight Host Routing using LLDP", Clarence Filsfils, Pablo Camarillo, Daniel Bernier, 2025-03-03, Link Layer Discovery Protocol (LLDP) is widely deployed today for discovery of information across network elements like routers, switches, and hosts. This document extends LLDP to allow hosts to advertise their IP prefixes to their attached routers which can then propagate the reachability of these host prefixes into routing protocols for enabling network-wide connectivity. "IS-IS Extensions for Load Balancing Alternates", Jie Dong, Xuesong Geng, Yunke Chen, Jie Xu, Geng Zhang, Shunxing Yang, 2025-03-03, IGP normally computes the shortest paths in the network based on the IGP metric, without taking the link utilization into consideration. In network scenarios where there is link degradation or failure which causes link throughput reduction, or the volume of specific traffic flows increase dramatically, congestion can happen if only the best path is used for forwarding. This document describes IS-IS extensions for the computation of alternate traffic engineering paths which can be used for traffic load balancing when the shortest path is becoming congested. "Adapting Home Routers to Congestion Control's Reactions for Consistent Low Latency", ZhangBochun, Zili Meng, 2025-03-03, This document describes Confucius -- a practical queue management scheme designed for offering real-time flows with consistently low latency regardless of competition. Confucius employs an age-aware weight adjustment mechanism to slows down bandwidth adjustment to match the reaction of congestion control, so that the end host can reduce the sending rate without overshooting the network. Confucius is deployed on home routers and requires no configuration in normal Internet deployments. "IPv6 Network Deployment Monitoring and Analysis", Ran Pang, Jing Zhao, Mingshuang Jin, Shuai Zhang, 2025-03-03, This document proposes an IPv6 network end-to-end monitoring and analysis framework. The aim is to address key issues existing in current IPv6 deployment monitoring, such as limited coverage, insufficient depth of analysis, and lack of cross-domain collaboration. "SPICE Use Cases in Telecom Network", Yurong Song, Lun Li, Wangdonghui, Fei Liu, 2025-03-03, This document describes use cases of the credential specific to the telecom network. It aims to propose benefits and scenarios regarding to introducing the credential to the telecom network, which can provide more scenarios and directions to Secure Patterns for Internet CrEdentials (SPICE) specifications. "Clarifications to the DNS Ranking Data", Kazunori Fujiwara, Willem Toorop, 2025-03-03, This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181, and specifies directives whereby the source of the data determines for what purposes it may be used. "Automatic Network Congestion Relief", Jing Zhao, Shuai Zhang, 2025-03-03, This document introduces an automatic congestion relief mechanism based on intelligent traffic analysis and dynamic regulation. In the event of congestion caused by fiber optic failures, it can respond intelligently and self-heal in real time, ensuring the stable operation of the network. "Fast Reroute based on Programmable Data Plane (PDP-FRR)", Dan Li, Kaihui Gao, Shuai Wang, Li Chen, Xuesong Geng, 2025-03-03, This document introduces a fast reroute architecture within the programmable data plane (PDP-FRR) for enhancing network resilience through rapid failure detection and swift path migration, leveraging in-band network telemetry and source routing. Unlike traditional methods that rely on the control plane and face significant delays in rerouting, the proposed architecture utilizes a white-box modeling of the data plane to distinguish and analyze packet losses accurately, enabling immediate identification for link failures (including black- hole and gray failures). By utilizing in-band network telemetry and source routing, the proposed solution significantly reduces reroute times to a few milliseconds, offering a substantial improvement over existing practices and marking a pivotal advancement in failure tolerance. "KVCache over MoQT", Hang Shi, 1211176911910469110103, 2025-04-09, Large language model (LLM) inference involves two stages: prefill and decode. The prefill phase processes the prompt in parallel, generating the KVCache, which is then used by the decode phase to produce tokens sequentially. KVCache can be reused if the model and prompt is the same, reducing computing cost of the prefill. However, its large size makes efficient transfer challenging. Delivering these over architectures enabled by publish/subscribe transport like MoQT, allows local nodes to cache the KVCache to be later retrieved via new subscriptions, saving the bandwidth. This document specifies the transmission of KVCache over MoQT. "Encryption of SRv6 Function in SRv6 Network", Zongpeng Du, 2025-03-03, This document describes an encryption mechanism for the SRv6 function in the SRv6 nodes. "A Public Key Service Provider for Verification in Multiple Issuers and Verifiers", Wangdonghui, Fei Liu, Lun Li, 2025-03-03, SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure. "Requirements and Deployments for High-Speed IoV based on SRv6", Xinrui Gu, Xinxin Yi, Naihan Zhang, 2025-03-03, This document proposes a deployment scheme for high-speed IoV by utilizing CATS, IFIT, SRv6, and network slicing technologies. Requirements and problems are discussed, and a deployment scheme is described in detail. "ACK Frequency Adjustment in Receiver", Zongpeng Du, 2025-03-03, This document describes a mechanism for adjusting ACK frequency in the receiver. "Extensible YANG Model for Network Telemetry Messages", Ahmed Elhassany, Thomas Graf, 2025-06-13, This document defines an extensible message schema in YANG to be used at the data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables a data collection to add metadata for the provenance of the operational network data. "JWTClaimConstraints profile of ACME Authority Token", Chris Wendt, David Hancock, 2025-06-13, This document defines an authority token profile for handling the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. This profile follows the model established in Authority Token for the validation of TNAuthList but is specifically tailored for the JWTClaimConstraints certificate extensions. The profile enables validation and challenge processes necessary to support certificates containing both TNAuthList and JWTClaimConstraints, particularly in the context of Secure Telephone Identity (STI). "Synchronizing BMP Monitoring Options and State", Nan Geng, Shunwan Zhuang, 2025-03-03, This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector. "Requirements Analysis of System and Network for Large Language Model Inference Service", Liu Chang, Chuyi Guo, 2025-03-03, With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, among which the vLLM proposed in 2023 is the most representative. This paper investigates mainstream inference frameworks, summarizes their core design principles, and analyzes the requirements and challenges they impose on system and network configurations. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. "Operations, Administration and Maintenance (OAM) for Network Resource Partition (NRP) in SR", Liyan Gong, Changwang Lin, 2025-03-03, A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in Segment Routing (SR) networks. By extending existing OAM mechanisms such as ping, traceroute, Bidirectional Forwarding Detection (BFD), and Simple Two-way Active Measurement Protocol (STAMP), the proposed solution enables comprehensive NRP support in SR networks. "Interface to In-Network Computing Functions (I2ICF): Problem Statement", Jaehoon Jeong, Yiwen Shen, Yoseop Ahn, Younghan Kim, Elias Duarte, Kehan Yao, 2025-03-03, 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. "RPP Architecture", Pawel Kowalik, Maarten Wullink, 2025-03-16, 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. "A Framework for LLM-Assisted Network Management with Human-in-the-Loop", Yong Cui, Mingzhe Xing, Lei Zhang, 2025-03-03, This document defines an interoperable framework that facilitates collaborative network management between Large Language Models (LLMs) and human operators. The proposed framework introduces enhanced telemetry module, LLM decision module and standardized interaction data models between human operators and LLM-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. "A Framework for the Interface to In-Network Computing Functions (I2ICF)", Jaehoon Jeong, Yiwen Shen, Yoseop Ahn, Younghan Kim, Elias Duarte, Kehan Yao, 2025-03-03, 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. "Interfaces of In-Network Computing Functions in Data Center Networking", Kehan Yao, Wenfei Wu, Jaehoon Jeong, 2025-03-03, In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Computing Functions (ICF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these ICFs. This document focuses on the applicability of ICFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these ICFs. "libZK: a zero-knowledge proof library", Matteo Frigo, abhi shelat, 2025-03-03, This document defines a technique for generating a succinct non- interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0. "Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems", Byoungman An, Jaehoon Jeong, Seonghyun Jang, 2025-03-03, 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. "Large Model based Agents for Network Operation and Maintenance", Chuyi Guo, 2025-03-03, 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. "Source Address Validation Deployment Status", Shuai Wang, Dan Li, Li Chen, Ruifeng Li, Lin He, 2025-03-03, This document provides a summary of methods for measuring the deployment status of source address validation, with an overview of its deployment status. It reviews various methods for measuring outbound and/or inbound source address validation, including established tools like CAIDA Spoofer, as well as recently proposed remote measurement methods. By combining results from these different methods, the document offers a comprehensive overview of the status of source address validation deployment across the Internet. "Remote Attestation MultiVerifier", Yogesh Deshpande, zhang jun, Henk Birkholz, 2025-03-03, 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. 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/ietf-rats/draft-deshpande-multi-verifier. "Additional CATS requirements consideration for Service Segmentation-related use cases", Tran Ngoc, Younghan Kim, 2025-03-25, This document discusses possible additional CATS requirements when considering service segmentation in related CATS use cases such as AR-VR and Distributed AI Training "YANG Datastore Telemetry (YANG Push Lite)", Robert Wilton, Holger Keller, Benoit Claise, Ebben Aries, James Cumming, Thomas Graf, 2025-03-03, 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. "Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework", Marco Tiloca, Goeran Selander, 2025-03-03, This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. "QUIC NAT", Zhiqiang Li, Wei Cheng, Junjie Wang, 2025-03-03, QUIC uses UDP as its transport layer protocol. Many existing NAT routers rely on observing TCP SYN, ACK, and FIN packets to determine the establishment and termination of connections, thereby precisely maintaining the lifecycle of NAT mapping entries. For QUIC, NAT devices can only manage mapping entries based on ordinary UDP aging mechanisms, which may cause NAT entries for long-lived QUIC connections to be prematurely aged and re-bound, resulting in changes to source ports. This document proposes a solution that extends the IP header options field to identify QUIC connections, facilitating NAT devices that do not recognize QUIC to accurately determine the lifecycle of QUIC connections and prevent random aging and re-mapping of long-lived QUIC connections. "Congestion Detection Optimization", Zhiqiang Li, Wei Cheng, Junjie Wang, 2025-03-03, This draft proposes an adaptive congestion detection mechanism for high-throughput data transmission in wide area networks (WANs). With increasing network bandwidth (up to 800Gbps) and challenges in traditional TCP-based protocols (e.g., throughput degradation over long distances and high packet loss rates), the solution focuses on optimizing congestion identification while minimizing bandwidth overhead. "Default Policy and Related Metrics in CATS", Zongpeng Du, Kehan Yao, Daniel Huang, Zhihua Fu, 2025-03-03, This document describes the considerations and requirements of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). Especially, it suggests that a default policy should be supported on the Ingress, and one or more default metrics should be included in the notification. "Adaptive Load Balance Enhancement", Zhiqiang Li, Zongpeng Du, Wei Cheng, Junjie Wang, 2025-03-03, This draft proposes an adaptive load-balancing mechanism to address high-throughput transmission challenges in East-West computing, data exchange, and DC interconnection services. Traditional methods-ECMP, RPS, and Flowlet-face limitations: ECMP suffers from hash collisions and load imbalance; RPS risks TCP packet reordering; Flowlet depends on impractical manual thresholds for burst interval configuration, leading to suboptimal performance. "KEM based Authentication for the IKEv2 with Post-quantum Security", Guilin WANG, 2025-03-03, This draft specifies a new authentication mechanism, called KEM based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. This is motivated by the fact that ML-KEM is much more efficient that ML-DSA, which are the post-quantum algoirhtms for mitigating the pontential security threats again quantum computers. The KEM based authenticationth for the IKV2 is achieved via introduing a new value of the IKEv2 Authentication Method registry mantained by IANA. For using the new authentication method, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined by [RFC9593]，to negotiate the supported KEM algorithms. After that, the correponding KEM certificates and cipthertext are exchanged via the INTERMEDIATE Exchange. Finally，the IKE messages are authenticated via the shared secret encapsulated between the two peers. This documents also specifies the instantiation with ML-KEM for this new general authenticaiton method for the IKEv2. [EDNOTE: Code points for KEM-based authentication may need to be assigned in the IKEv2 Authenticaion Method registry, maintained by IANA] "SR-MPLS Aggregation Segment", Bruno Decraene, Ketan Talaulikar, Syed Raza, Shraddha Hegde, 2025-03-03, One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. Contrary to this, MPLS forwarding works on exact match on MPLS labels. This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. This document introduces an Aggregation Segment for Segment Routing with MPLS data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks. "Source Address Validation Using Source Address Authorizations (SOAs)", Ren Gang, Minglin, Jia, Xia Yin, 2025-03-03, Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to validate the authenticity of source address of packets. Source Address Authorization (SOA) is a newly defined cryptographically signed object; it provides a means of recording information about the last Autonomous System (AS) traversed by packets before reaching a specific AS. When validated, the eContent of an SOA object confirms that the holder of the listed AS Number (ASN) has authorized the specified pre-ASes. This enables other ASes to collaboratively filter spoofed traffic, enhancing global Internet security by mitigating source address spoofing and DDoS attacks. "Terminal Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring", Carlos Bernardos, Alain Mourad, 2025-03-03, 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 connected to a network infrastructure, to benefit from transparent mobility management adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. "Information Element for Flow Discard Classification", John Evans, Oleksandr Pylypenko, Karim Cheaito, 2025-03-03, This document defines a new IPFIX Information Element for classifying flow-level discards which aligns with the information model defined in [I-D.ietf-opsawg-discardmodel]. The flowDiscardClass Information Element provides consistent classification of packet discards across IPFIX implementations, enabling correlation between device and interface-level statistics and impacted flows. "BGP Flowspec Redirects to SR Policy", Zhenqiang Li, liusong, 2025-03-03, Flowspec, an extension to BGP, enables the dissemination of traffic flow specification rules and can be used to steer traffic into SR Policy. However, existing approaches using Flowspec to direct traffic into a SR Policy have certain drawbacks (for details, refer to section 1). This document difines two new standard actions for the BGP Flowspec V2 protocol (FSv2) [I-D.ietf-idr-flowspec-v2]: Redirect to SR Policy Action and SRv6 SID Action. The former allows traffic to be directed to a designated SR Policy, while the latter enables the encapsulation of an additional SRv6 SID as needed during redirection. These extensions address the shortcomings of existing solutions. "Yang Data Model for supporting multipath IGMP/MLD proxies", Hongji Zhao, Luis Contreras, Xufeng Liu, 2025-03-03, The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. "Computing Energy Consumption Path in Segment Routing Networks", Yisong Liu, Changwang Lin, 2025-03-03, 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. "PCEP extensions for energy consumption", Changwang Lin, Yisong Liu, 2025-03-03, [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. "Flexible Algorithms for Energy Efficiency", Jinming Li, Changwang Lin, 2025-03-03, [draft-liu-spring-sr-policy-energy-efficiency-00] describes how energy consumption information is utilized for path selection in Segment Routing (SR) networks. This document elaborates on extending IGP protocols to carry energy consumption information, enabling its dissemination within the IGP domain and ultimately transmitting it to the controller. This allows the controller to perform routing calculations based on energy consumption metrics. "BGP-LS extensions for energy efficiency", Yisong Liu, Changwang Lin, 2025-03-03, [draft-liu-spring-sr-policy-energy-efficiency-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 elaborates on extending BGP-LS to carry energy consumption information and transmit it to the controller, enabling the controller to perform routing calculations based on energy consumption metrics. "Verifiable STI Persona (VESPER) Use Cases and Requirements", Chris Wendt, 2025-03-03, This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called VESPER (Verifiable STI PERsona). VESPER enhances STIR by incorporating a trust framework that associating a responsible business entity and/or human with the assignment and right-to-use a telephone number. Important to the use-cases and requirements are mechanisms for the preservation of privacy and explicit choice to reveal information beyond the communications service provider you have chosen to assign the telephone number with. Core to this premise is the ability to represent and prove the right to use a telephone number resource via the legitimate holder of the Vesper token. Additional metadata and attributes can be vetted and attested via vetting policies and Know- Your-Customer (KYC) processes that are not defined as part of this effort but should follow jurisdiction specific best practices and policies that may exist. The framework allows for the leveraging of trusted and identified issuers to create a signed credential known as a VESPER token that will be defined including associated claims and potential paths for extensibility in the future. In addition, transparency mechanisms are explored to provide public logs or registries of certificates, keys, entity information, or telephone number details, if desired by the telephone number holder to improve trustability, visibility and accountability within the telephone ecosystem. This document covers various scenarios in which VESPER can be used to enhance trust in communications, focusing on common real-world deployments and corresponding requirements. This work is intended to complement and align with the framework described currently as a work in progress in [I-D.wendt-stir-vesper]. "RADIUS over QUIC", Feng Yang, Changwang Lin, 2025-03-03, 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. "Transparent Rate Optimization for Network Endpoints (TRONE) Protocol", Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar, 2025-03-03, On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. "Remote Attestation with Exported Authenticators", Thomas Fossati, Muhammad Sardar, Tirumaleswar Reddy.K, Yaron Sheffer, Hannes Tschofenig, Ionut Mihalcea, 2025-05-20, This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. 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. "Artificial Intelligence (AI) for Network Operations", Reza Rokui, Cheng Li, Daniel King, 2025-03-03, This document explores the role of the IETF and IRTF in advancing Artificial Intelligence for network operations (AINetOps), focusing on requirements for IETF protocols and architectures. AINetOps applies AI/ML techniques to automate and optimize network operations, enabling use cases such as reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance. The document addresses AINetOps for both single-layer IP or Optical networks and multi-layer IP/Optical networks. It defines the concept of AINetOps for networking and provides its operational benefits such as network assurance, predictive analytics, network optimization, multi-layer planning, and more. It aims to guide the evolution of IETF protocols to support AINetOps-driven network management. "Multipath Traffic Engineering", Kireeti Kompella, Luay Jalil, Mazen Khaddam, Andy Smith, 2025-03-03, Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, nor the load balancing equally weighted to each next hop. Moreover, the desired destination may be reachable via multiple egresses. The proposal includes a protocol for signaling MPTE paths using various types of tunnels, some of which are better suited to multipathing. "Extensible Delegation for DNS using different transport protocols", Tim April, Petr Spacek, Ralf Weber, tale, 2025-03-03, This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in [I-D.draft-wesplaap-deleg], with ability to specify transport protocols and authentication parameters supported by name servers. "BGP SR Policy Extensions for Performance-Aware Path Selection", Zhenqiang Li, Liyan Song, 2025-03-03, 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 "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec", Rebecca Guthrie, 2025-03-03, This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information, and. This profile is made publicly available for use by developers and operators of these and any other system deployments. "DKIM2 Header Definitions", Bron Gondwana, Richard Clayton, Wei Chuang, 2025-03-03, This document describes the headers defined for DKIM2 and how they work togther to provide the behaviours that are designed into DKIM2. This is an early draft, a work in progress. "Signaling Zone Owner Intent", Leon Fernandez, Erik Bergstrom, Johan Stenstam, Steve Crocker, 2025-03-03, This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines a new DNS RRtype, HSYNC (Horizontal Synchronization), that enables zone owners to designate which providers are authorized to serve and/or sign their zones, control whether providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC record allows DNS providers to discover each other and establish secure communication channels, either via DNS messages secured by SIG(0) signatures or via a RESTful API secured by TLS. This provider-to-provider communication via Agents enables automated coordination for tasks such as NS RRset management, zone transfers, and DNSSEC-related operations. This specification covers the provider discovery and communication establishment aspects. The document defines two new roles to facilitate this synchronization: the Agent responsible for provider-to-provider communication and the Combiner which merges unsigned zone data from the zone owner with managed data from providers. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in RFC8901) is an important application of this framework, the HSYNC mechanism supports broader provider synchronization needs. The specific synchronization algorithms for multi-signer operation are described in [I-D.draft-ietf-dnsop-dnssec-automation]. Specification for how to express these algorithms over provider-to- provider communication is left for a follow-up document. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. "Guidance for Authors writing text for the BGP Tunnel Encapsulation Attribute", Susan Hares, 2025-03-03, The BGP (RFC4271) Tunnel Encapsulation Attribute (TEA) is defined in RFC9012. Currently proposed BGP specifications in the IDR and BESS Working groups have defined new tunnels and new parameters for these tunnels in Sub-TLV. The Segment Routing usage of the TEA has suggested a number of new Sub-TLVs. This document provides guidelines to help authors quickly write correct text for new tunnels (defined in tunnel TLVs) and new Sub-TLVs. These guidelines are given as "templates" to aid new authors. More experience authors should view these templates as a list of expected content. One additional challenge for tunnels using the PMSI tunnels is to carefully define the interaction between PMSI tunnels and TEA tunnels. "Multicast Snooping Optimizations", Nathan Karstens, Zhaohui Zhang, Lenny Giuliano, Naveen Ashik, Joseph Huang, 2025-03-15, TODO: provide abstract "SR Policy Programming RPC", Zafar Ali, Cheng Li, Luay Jalil, Alex Bogdanov, Francois Clad, Samuel Sidor, 2025-03-19, The document specifies a Remote Procedure Call (RPC) for programming ephemeral states associated with an SR Policy. "An IETF URN Sub-Namespace for JSON Web Token Claims", Chris Charabaruk, 2025-03-03, This document establishes an IETF URN Sub-namespace for use with JSON Web Token claims. "SCONEPRO Taxonomy of throttling policies used worldwide", Kyriakos Zarifis, Sharad Jaiswal, Ilango Purushothaman, Jon Varsanik, Abhishek Tiwari, Matt Joras, 2025-03-19, This document provides a description of traffic throttling and a taxonomy of throttling policies used by CSPs worldwide. "A YANG Module for Entitlement Inventory", Marisol Amador, Camilo Cardona, Diego Lopez, 2025-03-03, This document proposes a YANG module for incorporating entitlements in a network inventory of entitlements. Entitlements define the rights for their holder to use specific feature(s) 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. "Commercial National Security Algorithm (CNSA) Suite Profile for SSH", Alison Becker, Casey Wynn, 2025-04-17, This document defines a base profile of SSH for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. "Commercial National Security Algorithm (CNSA) Suite Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME)", Alison Becker, Michael Jenkins, 2025-03-03, This document defines a base profile of S/MIME for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ S/MIME. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. "A reference architecture for direct presentation credential flows", Leif Johansson, 2025-03-03, This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. "Multicast Applicability for Distributed Consensus Systems", David Guzman, Dirk Trossen, Joerg Ott, 2025-03-03, This document questions the applicability of a multicast semantic for the distributed consensus problem. For this, it details the consensus problem and the solutions taken in current systems. It outlines how point-to-multipoint communication arises as part of the consensus solution. Then, it details a peer-centric realization of a permissionless approach, identifying key issues. These issues include communication costs, performance delays, and lack of finality. Hence, it discusses a multicast strawman and its expected improvements. "Update to RFC 8717: IETF Administrative Terminology", Rich Salz, 2025-04-01, RFC 8717 updated several RFCs pertaining to the organization of the IETF to use the term "Managing Director, IETF Secretariat" (MDS). As that term does not accurately reflect the organization or roles of the IETF staff, the MDS term is no longer relevant. This document removes mention of particular staff roles, and instead updates the source documents so that the job to be done, and who the responsible entity is, are described. "IGMP / MLD Extension for Signaling Eco-Mode", Luis Contreras, 2025-03-03, This document specifies an extension to IGMPv3 and MLDv2 messages to indicate eco mode in the delivery of multicast content based on the mechanism described in [RFC9279]. "Including Privacy Pass Tokens in TLS Handshakes", Tommy Pauly, Scott Hendrickson, 2025-03-03, This document defines a mechanism for TLS servers to request, and TLS clients to provide, Privacy Pass tokens as part of the Encrypted Client Hello in the TLS handshake. This creates a way to add support for anonymous attestation and rate-limiting to servers that are enforcing denial-of-service protections as part of processing TLS handshakes. "In-Place Bandwidth Update for MPLS RSVP-TE LSPs", Zafar Ali, Vishnu Beeram, Peter Schoenmaker, 2025-03-17, 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). "Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS", Michael Jenkins, Alison Becker, 2025-03-03, This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. "Proposal for experimentation with stateless IPv6 multicast source routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing Headers (MRH)", Toerless Eckert, 2025-03-03, This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/ SRv6 networks as well as BIER networks as a related effort. "Public Name Masquerade for TLS Encrypted Client Hello", Martin Thomson, Marwan Fayed, 2025-03-03, An alternative method for authenticating Encrypted Client Hello (ECH) retry configurations is described. This method enables the use of multiple public names for the same server anonymity set. "MoQ qlog event definitions", Lucas Pardue, Mathis Engelbart, 2025-03-16, This document defines a qlog event schema containing concrete events for MoQ. "ACP free "Automation Network Infrastructure" for simple in-network automation (aNI)", Toerless Eckert, Bing Liu, 2025-03-03, 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. "Composite ML-DSA Authentication in the IKEv2", Guilin WANG, 2025-03-03, This draft specifies composite ML-DSA authentication in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. Namely, the authenticaiton in the IKEv2 is completed by using a compiste signature of ML-DSA [FIPS203], the newly post-quantum digital singature standard, and one of the following traditional singature algorithms, SA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. These concrete composite algorithm specifications follow [OGPKF24]. Composite ML-DSA authenticatio is achieved by asking to add a new value in the "IKEv2 Authentication Method" registry [IANA-IKEv2], mantained by IANA. After that, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate the specific composite ML-DSA algoithms. [EDNOTE: Code points for composite ML-DSA authentication may need to be assigned in the "IKEv2 Authentication Method" registry, maintained by IANA] "BGP-Link State (BGP-LS) Advertisement of Flow Queue", Jinming Li, Changwang Lin, 2025-03-15, In the traffic congestion management of routers, queueing technology is generally used to classify and transmit traffic. Therefore, queue information indirectly reflects the congestion status of the router. This document makes the necessary expansion of the BGP-LS mechanism to send queue information to the network controller in a scalable way, enabling the network controller to understand the router's traffic congestion status and make appropriate adjustments to the network traffic. "Secure Asset Transfer Protocol (SATP) Implementation Guide", Hyojin Song, Yong-Geun Hong, Thomas Hardjono, 2025-03-03, This memo provides guidelines to developers of gateway systems, digital asset networks and client applications for the Secure Asset Transfer Protocol (SATP). Multiple gateways can represent the same digital asset network following the SATP standards, which necessitate basic implementation guidelines as outlined in this document. It also serves as an introduction to the SATP processing workflow for those new to the SATP standards. (Note. the initial draft (00) is submitted for a brief review regarding the document's direction by SATP WG members during IETF 12 in Bangkok, Mar 2025) "MoQT Test", Alan Frindell, 2025-03-03, This document specifies the moq-test protocol, a testing protocol for Media over QUIC (MOQ) implementations. moq-test utilizes the Track Namespace as parameters to the publisher, enabling flexible and customizable testing scenarios. "Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM", Guilin WANG, Leonie Bruckert, Valery Smyslov, 2025-03-03, Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the “harvest now and decrypt later” threat posed by cryptanalytically-relevant quantum computers. For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in IKEv2 as an additional key exchange mechanism. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ] "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", Ali Sajassi, Mankamana Mishra, Keyur Patel, Jorge Rabadan, Wen Lin, 2025-03-03, This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). This document obsoletes RFC9251 (Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)). "Proposal for Updates to Guidance on Packet Reordering", Greg White, Ingemar Johansson, Dibakar Das, 2025-03-15, 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. In addition, certain link types can introduce out-of-order arrivals at the end of the layer 2 link, which the receiving equipment is required to rectify by delaying higher sequenced frames until all lower sequenced frames can be delivered or are deemed lost. The delaying of higher sequenced frames is generally done without any knowledge of the higher layer protocols in use, let alone any knowledge of higher layer protocol contexts (e.g. TCP connections) in the case that the layer 2 link is carrying a multiplex of such contexts. It could, for example, be the case that all of the higher sequenced frames being delayed are carrying packets for different layer 4 contexts than a single lower- sequenced frame that triggered the delay. The result is that this "re-sequencing" operation can introduce delays that result in degradation of performance rather than improving it. Moreover, modern, performant TCP and QUIC implementations support features that significantly improve their tolerance to out-of-order delivery. This draft is intended to promote an analysis and discussion of the sensitivity of modern IETF protocols to out-of-order delivery, and to potentially develop new information for layer 2 technology standards regarding the need to assure in-order delivery to support IETF protocols. "Use Case and Challanges for the Deployment of Object-Based Media across the Internet", Rajiv Ramdhany, Nicholas Race, Daniel King, 2025-03-03, This document outlines the challenges and use cases for the deployment and operation of Object-Based Media (OBM), also known as Flexible Media (FM), across the Internet. It discusses key considerations such as compute-aware traffic steering, metric usage, bandwidth optimization, and latency reduction techniques. The intention of this document is to highlight specific challanges or areas where IETF investigation and applicable solutions are needed for the optimal deployment of OBM-based media services. "Requirements for HTTPS for Local Domains", Dan Wing, Erik Nygren, Michael Richardson, 2025-03-19, When connecting to servers on their local network, users are surprised to encounter user interfaces that display errors, show insecure connections, and block some HTTP features when missing a secure context. However, obtaining PKIX certificates for those servers is difficult for a variety of reasons. This document explores requirements for authenticating local servers. "Deadline Aware Streams in QUIC Multipath", Tony John, Till-Frederik Riechard, 2025-06-05, This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (QUIC-MULTIPATH) as well as QUIC itself. This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and ideally by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages the path identifiers introduced by the Multipath Extension for QUIC to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard endpoints using the Multipath Extension for QUIC. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths. Additionally, this proposal also maintains compatibility with QUIC itself, in order to deliver its benefits - albeit with limited effectiveness - even in scenarios where only a single path can or should be used. "CBOR Encoding for HTTPS-based Transport for YANG Notifications", Bharadwaja Chittapragada, Siddharth Bhat, Vartika Rao, Hayyan Arshad, Mohit Tahiliani, 2025-03-03, This document extends [I-D.draft-ietf-netconf-https-notif-15] by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes. "Per-flow based EVPN DF Election", Krishnaswamy Ananthamurthy, Ali Sajassi, Lukas Krattiger, 2025-03-03, The Ethernet Virtual Private Network (EVPN) solution offers procedures for electing a Designated Forwarder (DF) for multihomed Ethernet Segments. In this context, the Provider Edge (PE) router is responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device or network. This applies in cases of an all-active multihomed Ethernet Segment (ES) as well as for BUM and unicast traffic in the case of single-active multi- homing. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the Ethernet Segment, but lacks in providing per flow based DF within the given EVPN Instances (EVIs). "Staged IPv6 Transition of Domain Name Systems", Hirochika Asai, Takashi Tomine, 2025-03-03, This document specifies the three-stage IPv6 transition of Domain Name Systems (DNS) transport. The scope of this document is only the transport between authoritative servers and recursive servers, but does not include the transport of recursive servers for DNS clients. "CCNx Content Versioning", Hitoshi Asaeda, Htet Hlaing, Marc Mosko, 2025-03-03, 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]. "SHA-3 for HPKE", Deirdre Connolly, 2025-03-03, This document defines Secure Hashing Algorithm-3 (SHA-3) options for Hybrid Public-Key Encryption (HPKE) as registered KDFs. "Personal Data Portability Archive", Lisa Dusseault, Hans-Joerg Happel, Alexey Melnikov, 2025-03-03, This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. "Architectural Considerations for Environmentally Sustainable Internet Technology", Michael Welzl, Emile Stephan, Eve Schooler, Sebastien Rumley, Ali Rezaki, Jukka Manner, Carlos Pignataro, Marisol Amador, Jan Lindblad, Suresh Krishnan, Ari Keranen, Hesham ElBakoury, Luis Contreras, Alexander Clemm, Jari Arkko, 2025-03-04, This document discusses protocol and network architecture aspects that may have an impact on the sustainability of network technology. The focus is on providing guidelines that can be helpful for protocol designers and network architects, where such guidelines can be given. "Getting Nameservers in the New Delegation Protocol", Paul Hoffman, 2025-05-06, The DELEG Working Group has chosen a base protocol that describes how resolvers will be able to get a new DNS resource record to create a new process for DNS delegation. After a resolver gets this new type of record, it needs to know how to process the record in order to get a set of nameservers for a zone. This document lists many of the considerations for that process, including many open questions for the DELEG Working Group. More considerations and open questions might be added in later versions of this draft. Note that this draft is _not_ intended to become an RFC. It is being published so that the DELEG Working Group has a place to point its efforts about how resolvers get nameservers for a zone while it continues to work on choosing a base protocol. The work that results from this might be included in the base protocol specification, or in a new draft authored by some of the many people who have done earlier work in this area. "Distributed MLS", Mark Xue, Joseph Lukefahr, Britta Hale, 2025-03-15, 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). Still, 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 protocol for using MLS sessions to protect messages among participants without negotiating a common group state. "Forward Error Correction for the Bundle Transfer Protocol", Rick Taylor, 2025-03-15, This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. "RESTful Provisioning Protocol (RPP)", Maarten Wullink, Pawel Kowalik, 2025-03-15, This document describes a HTTP-based protocol for the provisioning and management of objects in a shared database. "SOCKS Protocol Version 5a", Torin Lancaster, 2025-03-15, This document describes SOCKS Protocol Version 5a (SOCKS5a), an evolution of the SOCKS Version 5 protocol [RFC1928] designed to enhance security, authentication flexibility, and resistance to traffic analysis while maintaining complete backward compatibility. SOCKS5a introduces optional extensions that allow existing SOCKS5 clients and servers to interoperate with newer, more secure implementations. "RTP Header Extension for Automatic Detection of Video Corruptions", Erik Sprang, 2025-03-16, This document describes an RTP header extensions that can be use to carry select filtered samples from a video frame together with metrics relating to the expected distortions caused by lossy compression of said frame. This data allows a receiver to validate that the output from a decoder matches the frame the went into the encoder on the remote - i.e. validating that the video pipeline is in a correct state free of any video corruptions. "Transport Layer Protocol Requirement for LEO satellite", Feng Yang, Tina Tsou, 2025-06-10, In recent years, high-bandwidth LEO (Low Earth Orbit) satellite networks, such as Starlink and OneWeb, have seen tremendous development and are gradually becoming an important part of the global Internet. However, due to the unique characteristics of satellite networks, using TCP for data transmission faces challenges in multiple aspects, such as high latency caused by long-distance propagation and high error rates due to signal attenuation. This proposal summarizes the basic requirements that need to be considered for designing transport layer protocols tailored to LEO satellites. "TLS For Secure Element Rendez Vous", Pascal Urien, 2025-03-16, TLS for Secure Element (TLS-SE) is a TLS 1.3 profile for secure element. The pre-shared-key (psk) mode requires two security attributes, psk-identity and psk value, somewhat similar to login and password parameters used for classical users accounts. A rendez vous mechanism works with two accounts with different privileges. A root account generates contents and creates guest account with dedicated access rights for these contents. It is a kind of trusted publish-subscribe mechanism based on a TLS1.3 server running in a secure element. "Methods for Mitigation of Congestion and Load Issues on RADIUS Servers", Jan-Frederik Rieckers, 2025-03-16, 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. "SSH Support of ML-DSA", Scott Fluhrer, 2025-06-12, This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. "Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 17.0.0", Patrik Faltstrom, 2025-03-16, This document describes the changes between Unicode 12.0.0 and Unicode 17.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. The review assigns the derived property value "UNDER REVIEW" to certain code points. This is added as exceptions to the algorithm for IDNA2008 that allows adding exceptions to the algorithm for backward compatibility exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 17.0.0. "3GPP-IETF Standardization Collaboration", Suresh Krishnan, Charles Eckel, Peter Schmitt, 2025-03-17, This document contains a set of principles and guidelines that serve as the basis for the collaboration between 3GPP and IETF, with the objective of securing timely development of technical specifications, and to facilitate maximum interoperability with existing fixed and mobile Internet systems, devices, and protocols. "RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement", Erik Sprang, 2025-03-17, 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. "SSH Strict KEX extension", Damien Miller, 2025-03-18, This document describes a small set of modifications to the Secure Shell (SSH) protocol to fix the so-called Terrapin Attack on the initial key exchange. "Decentralized Messaging Layer Security", Konrad Kohbrok, 2025-03-17, Messaging Layer Security provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). However, MLS requires a Delivery Service (DS) to facilitate agreement between group members on the order of Commit messages. In decentralized settings the only way to implement a functional DS is to require group members to retain key material so they can process commits out-of-order. Retaining key material this way is in violation of the MLS deletion schedule and significantly reduces the FS of the protocol. This draft specifies Decentralized MLS, based on the 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 minimal losses to FS, thus allowing safer deployment in decentralized environments. "Decentralized Messaging Layer Security", Konrad Kohbrok, 2025-03-17, Messaging Layer Security provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). However, MLS requires a Delivery Service (DS) to facilitate agreement between group members on the order of Commit messages. In decentralized settings the only way to implement a functional DS is to require group members to retain key material so they can process commits out-of-order. Retaining key material this way is in violation of the MLS deletion schedule and significantly reduces the FS of the protocol. This draft specifies Decentralized MLS, based on the 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 minimal losses to FS, thus allowing safer deployment in decentralized environments. "FrodoKEM: key encapsulation from learning with errors", Patrick Longa, Joppe Bos, Stephan Ehlen, Douglas Stebila, 2025-03-17, This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). 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-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. "DKIM2 Procedures for bounce processing", Allen Robinson, 2025-03-17, This memo provides a description of the procedures for bounce processing that should be performed by any mail system that implements DKIM2, as part of the overall DKIM2 protcol definition. "Code Point Exhaustion in OpenPGP", Andrew Gallagher, 2025-03-18, This document specifies variable-length encoding mechanisms to expand the current one-octet OpenPGP registries beyond 256 values. "Secure Shell Key Exchange Method Using Chempat Hybrid of FrodoKEM-976 and X25519 with SHA-512: frodokem976x25519-sha512", Simon Josefsson, 2025-03-18, This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on FrodoKEM (FrodoKEM-976) 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-frodokem/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-frodokem. "SSH Certificate Format", Damien Miller, 2025-04-22, 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. "PACC - Automatic configuration for mail servers, calendar and contacts sync", Ben Bucksch, 2025-03-19, Set up a mail account with only email address and password. This uses the DNS SRV mechanism to find the configuration. It is meant for new mail servers that adapt their configuration to current best practices. "Fixed AES-GCM modes for the SSH protocol", Damien Miller, 2025-03-19, This document describes the use of the AES-GCM AEAD in the Secure Shell (SSH) protocol, using the underlying construction of [RFC5647] but fixing problems in the negotiation mechanism. "DPU-Based Bare Metal Management and Control Solution", Yi Yue, Wei Zhu, Tengfei SUI, 2025-03-19, This document proposes a DPU-based bare metal management solution to address inefficiencies in management and resource utilization associated with traditional bare metal deployments. The core idea of this solution is to leverage the DPU's high-performance processing and network acceleration capabilities, transforming traditional network/resource management into a DPU-centric control model. This not only simplifies bare-metal operations but achieves unified management across virtualized and physical environments through a consolidated framework. "Delete-Cookie", Yoav Weiss, 2025-03-20, This document specifies a Delete-Cookie HTTP header that instructs clients to delete cookies of certain names, without requiring the server to know more details about them. "HttpOnly cookie prefix", Yoav Weiss, Matthew Metzger, 2025-04-09, This draft introduces the __HttpOnly and __HostHttpOnly cookie name prefixes that ensure the cookie was set with an HttpOnly attribute. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://yoavweiss.github.io/httponly_prefix/draft-httponlyprefix- weiss-http.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-httponlyprefix-weiss-http/. Source for this draft and an issue tracker can be found at https://github.com/yoavweiss/httponly_prefix. "Updates to OAuth 2.0 Client Asseertion Authentication and Assertion Based Authorization Grants", Michael Jones, Chuck Mortimore, Brian Campbell, 2025-03-20, TODO Abstract "SMPT VERP Service Extension", Steffen Nurpmeso, 2025-03-31, This specification makes official D. J. Bernstein's Variable Envelope Return Paths: VERP. "Synchronizing caches of DNS resolvers", Stephane Bortzmeyer, Willem Toorop, Babak Farrokhi, Moin Rahman, 2025-03-23, Network of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. "Initialisation of Zone Files on the DNS Primary Server", Karl Dyson, 2025-03-25, This document describes an update to "DNS Catalog Zones" ([RFC9432]) that facilitates a method for the primary server of a DNS zone to create the underlying master file for member zone(s) using information contained within a catalog zone. 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/karldyson/draft-dyson-primary-zonefile- initialisation. "BGP SR Policy Candidate Path State Extend Flags", Changwang Lin, Ran Chen, 2025-03-23, [draft-ietf-idr-bgp-ls-sr-policy]The SR Candidate Path State TLV conveys the operational status and attributes of an SR Policy at the candidate path level. The SR Candidate Path State is frequently extended to carry new attributes and states for CPaths. However, only a few bits remain unassigned in the Flags field of the current implementation. This document addresses the issue of insufficient flag bits in the SR Candidate Path State TLV by defining a variable-length SR Candidate Path State Extend TLV for BGP-LS SR-Policy. This enhancement ensures scalability and flexibility in signaling additional attributes and states for SR Policy candidate paths. "IMAP Extensions Suggestions", Ricardo Signes, 2025-03-25, This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. "Resource Public Key Infrastructure (RPKI) Signed Messages (RSMs)", Q Misell, Job Snijders, 2025-03-26, This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a signature over a detached message. This document is an iteration on RPKI Signed Checklists (RSCs) [RFC9323] to include an explicit purpose and audience, to allow for more secure automated processing. Discussion 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/AS207960/draft-blahaj-sidrops-rsm. "Guidelines for Writing an IANA Considerations Section in RFCs", Amanda Baber, Sabrina Tanamal, 2025-03-25, 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. "Early IANA Code Point Allocation for IETF Stream Internet-Drafts", Amanda Baber, Sabrina Tanamal, 2025-03-25, This memo describes the requirements for securing IANA code point assignments before RFC publication. In particular, it describes the "early allocation" process that allows for temporary but renewable allocations from registries that would ordinarily require an IESG- approved Internet-Draft: namely, registries maintained in accordance with the "Standards Action," "IETF Review," "RFC Required," and, in some cases, "Specification Required" policies. This process can be used when code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication. The procedures in this document are intended to apply only to IETF Stream documents. This document obsoletes RFC 7120. "DNS Catalog Zone Properties for Zone Transfers", Aleksi Suhone, Willem Toorop, Anand Buddhdev, 2025-03-26, This document specifies DNS Catalog Zones Properties that define the primary name servers from which specific or all member zones can transfer their associated zone, as well as properties for access control for those transfers. "Concise Selector for Endorsements and Reference Values", Paul Howard, Thomas Fossati, 2025-06-12, 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. "Bits in ABNF", Doug Royer, 2025-03-27, This is an extension to the ABNF specification to allow for bits definitions to be defined. When interacting with hardware or bit oriented over the wire protocols ABNF is not currently the choice. This specification describes a method to add boolean and narrow bit values in order to fix that limitation. And this note while in in draft status: A new Open Source XDR [RFC4506] and ABNF generation tool is being developed [xdrgen] which generates code from ABNF and XDR. It can also generate ABNF from XDR. And it can generate XDR from ABNF. Both also can produce C++ source and header files. "Bits in XDR", Doug Royer, 2025-03-27, This is an extension to the XDR specification to allow for bits to be described and sent. With protocols that have a large number of boolean values the existing standard requires each to be individually packed into a 32-bit value. This addition does not alter any existing XDR data streams or effect existing implementations. * This specification describes how to pack a bit-boolean and short bit-width data values into the 32-bit XDR block chunks. * And this specification describes how to describe them by extending "The XDR Language Specification" to include bits. * And a new namespace declaration type is specified to aid in the reduction of name collisions in large projects. While in draft status, a new Open Source XDR generation tool is being developed [xdrgen]. "Verifiable Voice Protocol", Daniel Hardman, 2025-04-24, Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making telephone calls. This eliminates trust gaps that scammers exploit. Like related technolgies such as SHAKEN, RCD, and BCID, VVP binds cryptographic evidence to a SIP INVITE, and verifies this evidence downstream. However, VVP builds from different technical and governance assumptions, and uses stronger, richer evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance than alternatives. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. "Enhanced Dynamic Capability for BGP", Enke Chen, Srihari Sangli, 2025-03-28, 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. "HGCP: A Voluntary Signing Framework for Human Expression in the Age of AI", Qiwen Tao, 2025-04-17, In an era where AI-generated content has become indistinguishable from human writing, the Human-Generated Content Protocol (HGCP) proposes a voluntary signing framework that enables human authors to publicly acknowledge their expressions. Rather than detecting or classifying content origin, HGCP allows individuals to declare, in a structured and verifiable format, that they take responsibility for a specific piece of content. The protocol is platform-neutral, identity-flexible, and suitable for both real-name and pseudonymous use. It does not evaluate accuracy, originality, or quality; it simply enables people to say: “This is mine, and I stand by it.” By providing a lightweight, human-first declaration format, HGCP aims to preserve the visibility of human agency within an increasingly synthetic information ecosystem. "Direct Knowledge Extension to Distance Vector Routing", Sebastian Mueller, 2025-03-30, Naive Distance Vector-based routing protocols like the Routing Information Protocol [RFC_1058] suffer from a phenomena called the "count to infinity problem" in the event of a network topology change. This Internet Draft extends a naive Distance Vector routing implementation with a simple flag that allows the network to recover quickly and reliably, with no chance of routing loops to occur. 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/Sebastianmueller22/network-protocol. "IPv5 -- The missing transition step", Lutz Donnerhacke, 2025-03-31, Despite IPv6 was developed to replace IPv4, the transition process did not and will not ramp up as expected. Major reason for stalled deployment is non-technical, but historical knowledge as well as established processes. The missing part between IPv4 and IPv6 is designed to help the migration efforts by addressing the non- technical needs for a smooth transition. "SCHClet - A Modular Approach to SCHC Architecture", Alexander Pelov, 2025-03-31, This draft introduces the concept of a SCHClet, a modular, atomic sub-function within the SCHC (Static Context Header Compression) framework. Drawing an analogy from chiplet technology in integrated circuits, a SCHClet is envisioned as a self-contained unit that encapsulates a specific SCHC function or set of functions. This modular approach allows for tailored implementations that can meet diverse use cases without the overhead of a full SCHC apparatus. By decomposing SCHC functionality into SCHClets, the framework becomes more adaptable, extensible, and easier to deploy generic network environments, applicable, but not limited to constrained networks. A technology which uses a SCHClet can be considered as built using the SCHC Framework. A generic SCHC Framework implementation which has all SCHClets implemented MUST be able to interoperate with any SCHClet, provided it has the corresponding configuration. For example, if one IPsec end-point uses a minimal SCHClet implementation, the other end-point may use a full SCHC implementation with the corresponding configuration. It may be said that a SCHClet is the minimal sub-function corresponding to a given SCHC Context. In this sense, we can see Ack-On-Err Fragmentation as a SCHClet. We may consider the Ack- Always Fragmentation as a SCHClet. Or we may consider the baseline fragmentations from RFC8724 (NoAck, AckAlways, AckOnErr) as a SCHClet, with the parameters defining which fragmentation mode is used. In any case, a developer may chose to use only the NoAck fragmentation (for example), and in this case they are using the NoAck Fragmentation SCHClet, which can even be further restricted to a fixed set of parameters, with different parameters unsupported by the implementation. "The Areion Cipher Algorithm and Its Use With IPsec", Yumi Sakemi, Satoru Kanno, 2025-03-31, This document specifies the integration of the Areion cryptographic permutation into IPsec. Areion is a novel cryptographic primitive designed to achieve significantly lower latency for encryption and hashing operations compared to traditional algorithms like AES-GCM, making it particularly suitable for high-performance VPNs and data center interconnect scenarios. This specification defines the use of Areion within Encapsulating Security Payload (ESP), including the associated keying materials and the necessary parameters for Internet Key Exchange (IKE). The Areion permutation is fully described in [I-D.sakemi-areion]. This document focuses on incorporating Areion into IPsec. "CBOR : : Core - CBOR Cross Platform Profile", Anders Rundgren, 2025-06-14, 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. "Update of the Simple Two-way Active Measurement Protocol (STAMP) Class-of-Service Optional Extension", Greg Mirsky, 2025-03-31, This document describes an optional extension to the Class of Service monitoring functionality of Simple Two-way Active Measurement Protocol that enables the upstream monitoring of the Explicit Congestion Notification and thus updates RFC 8972. "An HTTP Status Code to Indicate Request Noncomformity While Still Making Best-Effort Response", Silas Barta, 2025-04-01, This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource was accessed in a nonconforming manner but the request will be tolerated with reservation, while directing the client adhere to relevant protocols. "DomainAuth Version 1", Gus Narea, 2025-04-01, This document defines DomainAuth, a protocol to attribute digital signatures to domain names in such a way that verification can occur entirely offline without a prior distribution of public keys. Each signature is distributed as part of a self-contained "signature bundle" that encapsulates a complete chain of trust comprising: (1) a DNSSEC chain from the root zone to a TXT record containing a public key or its digest, (2) an X.509 certificate chain from the key specified in the TXT record to the final signing key, and (3) the digital signature in the form of a CMS SignedData structure. Finally, signatures can be attributed to the domain name itself (e.g. "example.com") or specific users (e.g. "alice" of "example.com"). "NAT Sub Address Protocol", Daniel McLarty, 2025-04-01, This document defines the NAT Sub-Address Protocol (NATSAP), a Layer 5 encapsulation protocol designed to facilitate seamless bidirectional communication with devices behind Carrier-Grade NAT (CG NAT). NATSAP introduces dynamic sub-addresses assigned by the NAT router, which external clients can use alongside the public IP to route traffic back to internal devices without requiring traditional port forwarding. This document also defines the Dynamic Sub-Address Assignment Protocol (DSAAP), to facilitate the acquiring of a NATSAP Sub-Address. The protocol offers backward compatibility with existing IPv4 infrastructure, efficient DNS-based service discovery, and simple, stateless mapping. By encapsulating application-layer traffic, NATSAP enables direct communication with devices behind NATs using a standardized socket notation and DNS records. "ML-DSA for Web Authentication", Aditya Mitra, Sibi Chakkaravarthy, Anisha Ghosh, Devi VS, 2025-04-01, This document describes implementation of Passwordless authentication in Web Authentication (WebAuthn) using Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. "Extensible Delegation for DNS", Philip Homburg, Tim Wicinski, Jesse van Zutphen, Willem Toorop, 2025-04-03, This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with resource record sets placed below a _deleg label in the apex of the delegating zone. This authoritative delegation point can be aliased to other names using CNAME and DNAME. This document proposes a new DNS resource record type, IDELEG, which is based on the SVCB and inherits extensibility from it. IDELEG RRsets containing delegation information will be returned in the authority section in referral responses from supportive authoritative name servers. Lack of support in the authoritative name servers, forwarders or other components, does not obstruct obtaining the delegation information for resolvers, as it is originally authoritative information that can be queried for directly. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed on the authoritative name servers. "New Key Share Extension for Classic McEliece Algorithms", Jonathan Wagner, Yongge Wang, 2025-05-29, RFC 8446 is modified to where another key share extension is introduced to accommodate both public keys and ciphertexts in ClientHello and ServerHello messages for post-quantum algorithms that have large public keys, including algorithms of the code-based cryptographic scheme Classic McEliece. "SRv6 for Deterministic Path Placement in AI Backends", Clarence Filsfils, Pablo Camarillo, Ahmed Abdelsalam, 2025-04-04, This document describes the use of SRv6 to enable deterministic path placement in AI backends, optimizing load balancing and congestion control for predictable GPU workloads. "SRv6 Converged DC Frontend and WAN", Clarence Filsfils, Pablo Camarillo, Kris Michielsen, 2025-04-04, The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through domains in a unified and stateless manner. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). This eliminates the complexities and inefficiencies associated with traditional fragmented network designs. The solution enhances scalability and enables flexible stateless service insertion by unifying the DC and WAN under a single SRv6 domain. "Drone-Based IP over Avian Carriers", Yang Chen, 2025-04-04, This document proposes an experimental protocol, IP over Avian Carriers using Drones (IPoAC-Drone), as an extension to the classic IPoAC (RFC 1149) for modern low-altitude economy applications. It describes how UAVs (Unmanned Aerial Vehicles) can be utilized as network carriers to provide a store-and-forward data transmission model. The document covers protocol design, operational considerations, and potential applications, including emergency communication, rural networking, and disaster recovery. "Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX)", Thomas Graf, Haomian Zheng, 2025-06-16, This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of G-PON Encapsulation Method entities in the Passive Optical Transport of the Optical Distribution Network. "Handling Unvalidated Data during DNSSEC Troubleshooting", Shuhan Zhang, Shuai Wang, Li Chen, Dan Li, Baojun Liu, 2025-04-07, Due to the prevalence of DNSSEC (Domain Name System Security Extensions) misconfigurations, many domain administrators troubleshoot the records of DNSSEC-signed domains via queries with CD (Checking Disabled) bit set. However, as DNS resolvers are not forced to perform DNSSEC validation for CD=1 queries, the unvalidated data introduced during troubleshooting could be mixed up with the routine ones in the resolver cache. Recent research has revealed that the reuse of the cached unvalidated data in subsequent resolutions could lead to the risk of Denial-of-Service (DoS). This document clarifies the definition of unvalidated data in the context of DNSSEC. Then, it demonstrates the DoS vulnerabilities of current DNS resolver implementations due to the reuse of cached unvalidated data. Accordingly, it provides several recommendations for DNSSEC- validating resolvers to handle the unvalidated data and mitigate the risk of DoS, so as to improve the availability of DNSSEC-signed domains. "YANG Data Models for Transport Network Rich-Detail Network Management (RDNM)", Chaode Yu, XingZhao, 谭艳霞, Nigel Davis, Daniel King, 2025-04-10, This document defines two extension YANG data models augmenting to TE topology and TE tunnel modules, based on the RDNM (Rich-Detail Network Management) requirements in transport networks. "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Tim Bruylants, Thomas Richter, Corentin Damman, Antonin Descampe, 2025-06-10, This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document is a necessary revision of RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing compliant implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications to its implementers and users. "Guidelines for Considering Operations and Management in IETF Specifications", Benoit Claise, Joe Clarke, Adrian Farrel, Thomas Graf, Samier Barguil, Carlos Pignataro, Ran Chen, 2025-06-13, New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define New Protocols or Protocol Extensions regarding aspects of operations and management that should be considered. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement for an "Operational and Management Considerations" section in Internet-Drafts, before they are progressed for publication as RFCs. "Instance Information for SDF", Carsten Bormann, Jan Romann, 2025-04-10, This document discusses types of Instance Information to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf) and will ultimately define Representation Formats for them as well as ways to use SDF Models to describe them. // The present revision –01 has been slightly updated from the // discussion at the 2025-04-09 ASDF meeting. "Semantic Definition Format (SDF) Extension for Non-Affordance Information", Jungha Hong, Hyunjeong Lee, 2025-04-08, 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, sdfNonAffordance, that enables comprehensive modeling of Things and improves semantic clarity. "A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators", Stefan Grimminck, 2025-04-09, This document defines a consistent and reversible method for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It introduces a safe obfuscation format to prevent accidental execution or activation when IOCs are displayed or transmitted. These techniques aim to standardize the safe dissemination of threat intelligence data. This specification uses the URI syntax defined in RFC 3986 and follows the key word conventions from RFC 2119. "Protocol for Automation Control", Liao Peiyuan, 2025-04-21, This document specifies a machine-readable protocol for server-side automation permissions in the light of recent advances in AI-driven web automation. Building upon RFC9309, this protocol addresses a broader range of state-changing activities that service owners may wish to control. It defines the file format, HTTP method restrictions, and purpose requirements. "Protocol Extension for Automation Control", Liao Peiyuan, 2025-04-21, This document specifies extensions to [CORE-SPEC], providing a wider range of controls for server-side automation permissions. It supports rate limiting, automation technology restrictions, API permissions, session requirements, and HTML asset annotations. These extensions enable service owners to exercise more granular control over automated interactions. "The IETF is for Everyone: Toward Inclusive and Equitable Participation in Internet Governance", MOHAMED Karim, 2025-04-22, This document affirms that the governance and activities of the IETF must be inclusive, accessible, and safe for all individuals, regardless of geography, language, race, gender, or sexual orientation. It expands on prior diversity and venue policy RFCs and calls for community reflection on enhancing participation through inclusive meeting practices and multilingual support. "Encrypted Authenticated Resource Locator", Phillip Hallam-Baker, 2025-04-10, 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. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. "OAuth 2.0 client extension claims", Jeff Lombardo, Alexandre Babeanu, 2025-04-11, This specification defines new claims for JWT profiled access tokens [RFC9068] so that resource providers can benefit from more granular information about the client to make better informed access decisions. The proposed new claims include: the client authentication methods, the client OAuth grant flow used as well as the OAuth grant flow extensions used as part of the issuance of the associated tokens. "JSContact Cryptographic Key Extensions", Phillip Hallam-Baker, 2025-05-10, Extensions to the JSContact data model for contact card data are defined to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card. These features in combination provide a basis for establishing and maintaining peer- to-peer trust. "Methods for IP Address Encryption and Obfuscation", Frank Denis, 2025-04-15, This document specifies methods for encrypting and obfuscating IP addresses, providing both deterministic format-preserving and non-deterministic constructions. These methods address privacy concerns raised in [RFC6973] and [RFC7258] regarding pervasive monitoring and data collection. The methods apply uniformly to both IPv4 and IPv6 addresses by converting them into a 16-byte representation. Two generic constructions are defined—one using a 128-bit block cipher and the other using a 128-bit tweakable block cipher—along with three concrete instantiations: * *ipcrypt-deterministic:* Deterministic encryption using AES128 (applied as a single-block operation). * *ipcrypt-nd:* Non-deterministic encryption using the KIASU-BC tweakable block cipher with an 8-byte tweak. * *ipcrypt-ndx:* Non-deterministic encryption using the AES-XTS tweakable block cipher with a 16-byte tweak. Deterministic mode produces a 16-byte ciphertext (enabling format preservation), while non-deterministic modes prepend a randomly sampled tweak (which MUST be uniformly random when generated, as specified in [RFC4086]) to produce larger ciphertexts that resist correlation attacks. 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/jedisct1/draft-denis-ipcrypt. "Neotec API Strategy and IETF Work Plan", Linda Dunbar, Nabeel Cocker, Chongfeng Xie, 2025-04-14, This document outlines a strategy for standardizing the Neotec (NetOps4Cloud) API through the IETF, modeled after the successful approach used in the GROW Working Group's Peering API draft. The objective is to define a vendor-neutral, cloud-provider-agnostic, and secure interface that enables real-time coordination between cloud service scaling events and dynamic network policy adjustments by network controllers. "HTTP Message Signatures Directory", Thibault Meunier, 2025-04-15, 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", Thibault Meunier, 2025-05-07, 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. "Hybrid Post-Quantum Password Authenticated Key Exchange", Jelle Vos, Stanislaw Jarecki, Christopher Wood, 2025-04-15, This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is the result of a KEM-based transformation from the hybrid symmetric PAKE protocol called CPaceOQUAKE that is also described in this document. This document recommends configurations for CPaceOQUAKE+. "Doing an Inventory of IoT devices using IDevID scanning", Michael Richardson, 2025-04-15, This document describes a mechanism to do an inventory of devices on a network. While there are significant abuse and privacy concerns with kind of scanning, the practice of scanning networks and fingerprinting devices has been occuring since the mid 1990s. But, the adhoc methods are not reliable and do not provide any kind of strong device identity. This document takes the approach that if it will happen, it might as well be reliable and secure. "LDP Extensions for Flex-Algo", Changwang Lin, Yisong Liu, 2025-04-15, This document specifies extensions to LDP to support the use Flex- Algo, enabling Label Switched Paths (LSPs) to follow a specific Flex-Algo. "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit Error Detection and Bit Error Rate Measurement", Rakesh Gandhi, Peter Schoenmaker, 2025-05-28, 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. This document further augments the STAMP extensions specified in RFC 8972 to enable the detection of bit errors and the measurement of the bit error rate within the "Extra Padding" TLV of STAMP packets. "Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case", Linda Dunbar, Sun Qiong, Bo Wu, Luis Contreras, 2025-05-05, 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. "Zixt Secure Messaging Protocol (ZSMP)", Ryan Huff, 2025-04-18, This document specifies the Zixt Secure Messaging Protocol (ZSMP), a protocol for secure, end-to-end encrypted messaging in the Zixt Chat application. ZSMP provides authentication, confidentiality, and integrity for messages exchanged between clients, with support for group messaging and extensibility. This specification defines the message formats, cryptographic mechanisms, and session management procedures for ZSMP. "Enforcing DNSSEC via HTTPS: Combining DANE and MTA-STS", Gunther Nitzsche, 2025-04-19, This document proposes a minimal, backward-compatible extension to the SMTP MTA-STS policy format by adding an optional field "dnssec:" to indicate whether the recipient domain operator expects DNSSEC validation to be active. This allows sending MTAs to detect silent DNSSEC stripping attacks and apply more secure delivery behavior accordingly. The mechanism leverages the existing HTTPS-secured delivery channel of MTA-STS and does not require changes to the DNS infrastructure or SMTP protocol. "CBOR Simple Value for CSF", Anders Rundgren, 2025-04-19, This document defines a CBOR "simple" value to be used as a unique label for a container map holding an embedded signature. "The agent:// Protocol -- A URI-Based Framework for Interoperable Agents", Yaswanth Narvaneni, 2025-04-21, 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. "Automated Summaries of IETF Contributions", Rob Sayre, 2025-04-22, Automated summaries of IETF contributions are permissible contributions. "OAuth Pushed Client Registration", Justin Richer, Aaron Parecki, 2025-04-22, This specification provides a way for an ephemeral or transactional OAuth 2.0 client to signal to the AS that the client does not need or expect to have an identified state outside the existence of any issued access and refresh tokens. The specification also enables a client to push its registration information to the AS during a pushed authorization request. "AS2 Specification Modernization", Debra Petta, 2025-04-22, 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. "PQuAKE - Post-Quantum Authenticated Key Exchange", Uri Blumenthal, Brandon Luo, Sean O'Melia, Gabriel Torres, David Wilson, 2025-04-22, This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure COmmunications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a preshared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs. "Best Practices for Persistent References in DNS", Swapneel Sheth, Andrew Kaizer, 2025-04-22, 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. "Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data", Rohan Mahy, 2025-04-22, 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. "Composite ML-DSA Signatures for SSH", Sun Shuzhou, Lucas Prabel, 2025-04-23, This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. "Unified Network and Cloud Orchestration Framework", Xueting Li, Cong Li, 2025-06-08, This draft introduces the Unified Network and Cloud Orchestration Framework (UNCO), which is designed to enable real-time and joint orchestration of network and computing resources in 5G and future- generation networks. UNCO framework addresses inefficiencies in current resource scheduling mechanisms, resolves objective conflicts across domains, and provides unified policy and security management. It is applicable in emerging scenarios such as ultra-reliable low- latency communications (URLLC), mobile edge computing (MEC), and network slicing, where service quality and operational efficiency are paramount. "DHCPv6 Active Leasequery over QUIC", Changwang Lin, 2025-04-24, RFC7653 allows for actively transferring the real-time binding information data of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) via TCP, which satisfies the need of continuous update of an external requestor with Leasequery data. QUIC could provide useful, reliable and secure semantics for transferring active leasequery of DHCPv6, which enabling much better efficiency and performance by reducing connect time. This document describes how to use the QUIC transport protocol to deliver DHCPv6 Active Leasequery messages, named DHCP6oQUIC. "Reverse HTTP CONNECT for TCP and UDP", Yaroslav Rosomakho, 2025-04-25, This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing. "Initialisation of DNSSEC Policy for DNS Catalog Zones Members", Karl Dyson, 2025-04-25, This document describes an update to "DNS Catalog Zones" ([RFC9432]) that facilitates a method to signal DNSSEC policy to DNSSEC signers for member zone(s) using information contained within a catalog zone. "Register a new reserved content coding value", Guohui Deng, 2025-04-25, This document proposes a new reserved value unknown for the HTTP protocol parameter content coding. "Network Traffic Analysis and Network Modal Mapping Method", Hui Yu, Yijun Mo, 2025-04-25, This document presents a framework for network traffic classification and modality mapping based on large language models (LLMs), addressing the inefficiencies of traditional methods in dynamic network environments. The proposed approach automates multi- dimensional traffic feature extraction and intelligent decision- making to achieve precise alignment between traffic patterns and computing-storage-transmission requirements. The framework comprises two phases: pre-training (generating multi-modal traffic representations from pcap data) and mapping (dynamically formulating resource allocation strategies). It supports anomaly detection, QoS assurance, and multi-service collaboration, thereby significantly enhancing resource utilization efficiency and network service performance. "JSON-Based Dynamic Configuration Management", Dogu Abaris, 2025-04-25, JavaScript Object Notation (JSON) is a widely used data interchange format, suitable for storing configuration data due to its simple syntax, machine-readable structure, and ease of parsing and generation. This document describes informational practices associated with JSON- Based Dynamic Configuration Management. It outlines a recommended naming convention for configuration files in the form of a structured filename pattern, such as "@.json", and specifies a configuration schema to support validation, traceability, and non- disruptive updates. The document also describes the rationale for standardization and presents real-world scenarios where these practices apply. "X.509 Certificate Extensions for Attestation Results", Mike Ounsworth, Monty Wiseman, Hannes Tschofenig, Tirumaleswar Reddy.K, Ned Smith, 2025-04-26, This document defines extensions for X.509 certificates to include attestation results as part of the certificate's content. The primary use case for these extensions is in the context of Certificate Signing Request (CSR) attestation, where claims about the trustworthiness of an Attester are conveyed to the Certification Authority (CA) as part of the CSR process. These extensions enable the CA to appraise the submitted evidence and embed attestation results into the issued certificate. This allows Relying Parties to evaluate the Attester's trustworthiness consistently and efficiently, supporting scalable policies for verification in environments with diverse attestation technologies. "Cross-Domain Cloud-Native Resource Orchestration Framework with Dynamic Weight-Based Scheduling", Zhou Chengyu, Yijun Mo, Hongyang Liu, yunhuipan, 2025-05-15, The Distributed Resource Orchestration and Dynamic Scheduling (DRO- DS) standard in cross-domain cloud-native environments aims to address the challenges of resource management and scheduling in multi-cloud architectures, providing a unified framework for efficient, flexible, and reliable resource allocation. As enterprise applications scale, the limitations of single Kubernetes clusters become increasingly apparent, particularly in terms of high availability, disaster recovery, and resource optimization. To address these challenges, DRO-DS introduces several innovative technologies, including dynamic weight-based scheduling, storage- transmission-compute integration mechanisms, follow-up scheduling, real-time monitoring and automated operations, as well as global views and predictive algorithms. "Secure Task-bound Agent Message Proof (STAMP) Protocol", Guy Bary, 2025-04-27, The Secure Task-bound Agent Message Proof (STAMP) protocol provides a cryptographically verifiable delegation and proof framework for AI- driven multi-agent systems. STAMP introduces task-bound access tokens and message-level proofs for agentic environments, binding tokens to specific user intents, tasks, and agent identities. STAMP tokens ensure that delegation, execution, and agent-to-agent communication comply with least-privilege and zero-trust security principles. STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of- possession (PoP) techniques, providing stronger security for dynamic, non-deterministic workflows involving autonomous agents. "Web bot auth Glossary", Thibault Meunier, 2025-04-28, Automated traffic authentication presents unique security challenges, constraints, and opportunities that impact all Internet users. This document seeks to collect terminology and examples within the space, with a specific focus on AI related technologies. "IETF Network Requirements", Jay Daley, 2025-05-21, This document aims to initiate a conversation to clarify the way forward to address disagreements within the community about the requirements for the IETF meeting network, how it is delivered and whether or not the current cost and effort of providing the network is reasonable. "DNS Security Extensions (DNSSEC)", Paul Hoffman, 2025-04-29, This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document obsoletes RFC 9364. This document is being tracked at (https://github.com/paulehoffman/ rfc9364bis). "Best Practice Recommendations for DS Automation", Steve Sheng, Peter Thomassen, 2025-04-30, 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. "AI Content Disclosure Header", Dogu Abaris, 2025-04-30, This document proposes a machine-readable Hypertext Transfer Protocol (HTTP) response header field, AI-Disclosure, to disclose the presence and degree of Artificial Intelligence (AI) generated or AI-assisted content in web responses. The header is designed for compatibility with HTTP structured field syntax and provides metadata for user agents, bots, and archiving systems. It supports layered disclosure strategies alongside human-readable and structured metadata formats. "Using 802.1AB (LLDP) for IETF LSVR neighbor discovery and configuration", Paul Bottorff, Paul Congdon, 2025-05-01, IEEE Std 802.1AB, known as the Link Layer Discovery Protocol (LLDP), can be applied to LSVR neighbor discovery and configuration. This can be achieved by using a nearest router group address as the LLDP Scope MAC Address to target LSVR interfaces while advertising a set of LSVR-specific LLDP TLVs. These LSVR-specific TLVs are defined using LLDP Organizationally Specific TLVs, as specified by LLDP for use by individual organizations to allow them to define their own Type-Length-Value (TLV) objects for exchange over the LLDP protocol. The IETF Organizationally Specific TLVs for LSVR can be encoded using the IETF IANA OUI (RFC 7042). This document provides an overview of applying LLDP to LSVR neighbor discovery and configuration and specifies the IETF Organizationally Specific TLVs that support link discovery for LSVR routers. In addition, a brief discussion of the use of IEEE Connectivity Fault Management (CFM) as specified in IEEE Std 802.1Q-2022 cl 18-22 for link liveliness is included. "DNS Zone Version (ZONEVERSION) Extended", Stefan Ubbink, 2025-05-02, The DNS Zone Version (ZONEVERSION) extended is a way to get information about the version of a DNS 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. This document will make it possible show the zone information which is the base of the presented data. "Federated Authentication of Entities", Jakob Schlyter, Stefan Halen, 2025-05-09, This document describes the Federated Authentication of Entities (FedAE) framework, enabling secure machine-to-machine communication within a federation. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedAE ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. "Network File System version 4.2 COPY Operation Implementation Experience", Olga Kornievskaia, Chuck Lever, 2025-05-02, This document describes the authors' experience implementing the NFSv4.2 COPY operation, as described in [RFC7862]. "The Network File System Access Control List Protocol", Chuck Lever, 2025-05-02, This Informational document describes the NFS_ACL protocol. NFS_ACL is a legacy member of the Network File System family of protocols that NFS clients use to access and modify Access Control Lists stored on an NFS version 2 or version 3 server. "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", Thilina Senarath, Ayesha Dissanayaka, 2025-05-08, This specification extends the OAuth 2.0 Authorization Framework [RFC6749] to enable AI agents to securely obtain access tokens for acting on behalf of users. It introduces the *requested_actor* parameter in authorization requests to identify the specific agent requiring delegation and the *actor_token* parameter in token requests to authenticate the agent during the exchange of an authorization code for an access token. The flow can be initiated by a resource server challenge, ensuring that user consent is obtained dynamically when access is attempted. This extension ensures secure delegation with explicit user consent, streamlines the authorization flow, and enhances auditability through access token claims that document the delegation chain from the user to the agent via a client application. "RSVP Cryptographic Authentication with HMAC-SHA2", Ran Atkinson, Joel Halpern, 2025-05-04, 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. "Framework, Use Cases and Requirements for AI Agent Protocols", Jonathan Rosenberg, Cullen Jennings, 2025-05-05, 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. "Reservation of f000::/4 for Structured Internal-Use IPv6 Addressing", Miller Wissen, 2025-05-05, This document proposes the reservation of the IPv6 address block f000::/4 for structured internal-use networking. This allocation extends the concepts of Unique Local Addresses (ULAs) as defined in RFC 4193, acknowledging the growing demand for a larger, more hierarchically organised, and clearly non-internet-routable address space for internal networks. The reservation of f000::/4 would prevent future conflicts with public allocations and provide operational clarity to large-scale, privacy-focused, or non-public infrastructures. "SR Policy Extensions for energy efficiency", Yisong Liu, Changwang Lin, 2025-05-06, [draft-liu-spring-sr-energy-efficiency-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 details the extensions to the BGP SR Policy and BGP-LS SR Policy to encapsulate the energy consumption information for each segment list of the SR Policy candidate paths, enabling its utilization in the route selection process. "ISIS Hierarchical SNPs", Tony Przygienda, Tony Li, 2025-05-08, The document introduces an optional, new type of SNPs called Hierarchical SNP (HSNP) that can compress the traditional CSNPs exchange into a variant of merkle tree, hence allowing to support very large databases and adjacency numbers. Such an approach should lead in case of inconsistencies to much faster re-synchronization since only a subset of packets compared to full scale CSNP exchange is necessary to correct the entropy present. "OAuth 2.0 App2App Browserless Flow", Yaron Zehavi, Henrik Kroll, Grese Hyseni, 2025-05-09, This document describes a protocol enabling native apps from any app publisher, using the [App2App] pattern, to achieve native user navigation without requiring a web browser. The native navigation is retained also when the Client uses any number of OAuth brokers to federate across trust domains, while offering highest levels of security. "Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV)", Li Qi, Yihao Chen, Ke Xu, Zhuotao liu, Jianping Wu, 2025-05-08, 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. "Fully Adaptive Routing Ethernet in Scale-Up Networks", Xiaohu Xu, Zongying He, Hua Wang, Tianyou Zhou, Yongtao Yang, Yinben Xia, Peilong Wang, Yan Zhuang, Fajie Yang, Chao Li, Xiaojun Wang, 2025-05-21, The Mixture of Experts (MoE) has become a dominant paradigm in transformer-based artificial intelligence (AI) large language models (LLMs). It is widely adopted in both distributed training and distributed inference. Furthermore, the disaggregation of the prefill and decode phases is highly beneficial and is considered a best practice for distributed inference models; however, this approach depends on highly efficient Key-Value (KV) cache synchronization. To enable efficient expert parallelization and KV cache synchronization across dozens or even hundreds of Graphics Processing Units (GPUs) in MoE architectures, an ultra-high- throughput, ultra-low-latency AI scale-up network (SUN) that can efficiently distribute data across all network planes is critical. This document describes how to extend the Weighted Equal-Cost Multi- Path (WECMP) load-balancing mechanism, referred to as Fully Adaptive Routing Ethernet (FARE), which was originally designed for scale-out networks, to scale-up networks. "JSDevice Device Description", Phillip Hallam-Baker, 2025-05-10, A JSON format for describing devices is described. Device descriptions provide identification information for the device and model number, images and video showing the device and its use, network configuration information and identifies associated consumable items, accessories and maintenance schedules. "Unobtrusive End-to-End E-mail Signatures", Andrew Gallagher, Daniel Gillmor, Kai Engert, 2025-05-11, This document deals with end-to-end cryptographically signed e-mail. It introduces a novel structure for signed e-mail that is designed to avoid creating any disturbance in legacy e-mail clients. This "unobtrusive" signature structure removes disincentives for signing e-mail. "BGP Signaled MPLS Namespaces", Kaliraj Vairavakkalai, Jeyananth Jeganathan, Praveen Ramadenu, Israel Means, 2025-05-12, The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. "QUIC compression using SCHC", Samar Sirohi, Laurent Toutain, 2025-05-12, This document specifies a mechanism for applying Static Context Header Compression (SCHC) to QUIC (Quick UDP Internet Connections) packets. It leverages SCHC to compress both the QUIC packet header and the headers or type information of QUIC frames contained within the packet payload. This approach aims to significantly reduce QUIC overhead, optimizing bandwidth usage. This is particularly beneficial for valuable in bandwidth-sensitive scenarios like deep space communications. This document defines the SCHC architecture. "Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies Use Case", Linda Dunbar, Sun Qiong, Bo Wu, Luis Contreras, 2025-05-12, This document explores how existing IETF YANG data models can be applied to support a use case involving dynamic, time-scoped UCMP (Unequal Cost Multipath) policy enforcement across multiple network segments interconnecting Edge Cloud sites. The use case is motivated by periodic, high-volume data exchanges between distributed AI inference modules placed at geographically dispersed edge data centers. By mapping network requirements such as bandwidth, latency, and availability to relevant YANG models, including AC, TE Topology, SR Policy, and QoS models, this document serves as a practical exercise to evaluate the applicability and limitations of current IETF specifications. It highlights the need for cloud-initiated, time-bounded network policy activation and identifies potential gaps in model expressiveness, policy lifecycle handling, and API-level abstraction required for real-time cloud-network coordination. "XRUDP eXtended Reliable UDP Protocol Specification", Torin Lancaster, 2025-05-12, XRUDP (eXtended Reliable UDP) is a modern UDP-based transport protocol providing reliable, in-order, message-oriented delivery with congestion control, security, NAT traversal, and extensibility. It is designed for scenarios demanding reliable and efficient message delivery over unreliable networks, such as real-time signaling, IoT, gaming, and edge computing. This document specifies the XRUDP packet format, state machine, negotiation, and interaction with applications. "OSPF Extensions for Precomputed Fast Reroute", Srinivasa Varigonda, Veerendranatha Vallem, 2025-05-12, This document proposes an enhancement to OSPF (Open Shortest Path First) that enables routers to precompute backup loop-free alternate (LFA) paths for fast reroute (FRR) in case of primary path failures. This mechanism improves convergence time and network stability by eliminating the delay associated with on-demand SPF recalculation during failure events. "SRv6 for PPPoE Transport", Cancan Huang, Xueyan Song, 2025-05-12, This document presents a method of utilizing IPv6 underlay tunnels to transfer the PPPoE session information in broadband networks. By taking advantage of the programmability of SRv6 SIDs, it not only enables trusted authentication and secure access for broadband users but also meets the needs of operators to provide differentiated services to broadband users and flexibly deploy services. "Congestion Control Based on SRv6 Path", Yisong Liu, Hang Shi, 2025-05-12, 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. "Precision Time Protocol (PTP) Authentication Extension", Srinivasa Varigonda, Rama Sige, 2025-05-12, Precision Time Protocol (PTP), as defined in IEEE 1588-2019, lacks cryptographic security mechanisms, exposing deployments to message spoofing, delay attacks, and timestamp manipulation. This document defines an optional Authentication TLV (AUTH_TLV) using modern Authenticated Encryption with Associated Data (AEAD) algorithms to ensure message integrity,authenticity, and replay protection. It also provides example configurations, implementation approaches, and test strategies. "Proof of Position for Auditor managed Endorsements", Michael Richardson, 2025-05-13, Some aspects of a device can not be intuited by the device itself. For instance, a router platform may have no way to know what color the case is, where in a cabinet it is located, or which electrical circuit it is connected to. This kind of information must be provided through an Endorsement: a statement from a third party. These statements may require human audiitors to inspect the device physically. But, which device is really in front of an auditor? This document describes a mechanism by which an auditor can make physical contact with a device and collect information to identify the device in a cryptographically strong manner. This protocol is not designed to run over Internet Protocol cabling, but rather over mechanisms such as USB cables, or serial consoles. "AAuth - Agentic Authorization OAuth 2.1 Extension", Pat White, 2025-05-13, This document defines the *Agent Authorization Grant*, an OAuth 2.1 extension for *confidential agent clients*—software or AI agents with long-lived identities—to request end-user consent and obtain access tokens via HTTP polling, Server-Sent Events (SSE), or WebSocket. It is heavily inspired by the core dance of the OAuth 2.0 Device Authorization Grant (RFC 8628) but is tailored for agents either long lived identities, and introduces scoped, natural-language descriptions and a reason parameter provided by the agent. "Manual OAuth 2.0 Configuration Profile for Mail Clients", Francis Medeiros-Logeay, 2025-05-13, This document defines a lightweight and interoperable profile for configuring OAuth 2.0 authentication in mail clients using a small number of manually entered parameters. The profile targets public clients using PKCE and discovery endpoints, avoiding the need for dynamic client registration or hardcoded provider logic. The goal is to make secure OAuth 2.0-based authentication for IMAP/SMTP universally deployable and user-configurable. "CBOR Serialization and Determinism", Laurence Lundblade, 2025-05-27, This document updates and clarifies CBOR Serialization and Deterministic Encoding as defined in [RFC8949]. It also provides background explanations that were not included in the original specification. "Manual OAuth 2.0 Configuration Profile for Mail Clients", Francis Medeiros-Logeay, 2025-05-13, This document defines a lightweight and interoperable profile for configuring OAuth 2.0 authentication in mail clients using a small number of manually entered parameters. The profile targets public clients using PKCE and discovery endpoints, avoiding the need for dynamic client registration or hardcoded provider logic. The goal is to make secure OAuth 2.0-based authentication for IMAP/SMTP universally deployable and user-configurable. "A Technique for Quering the Designated Authoritative Server Directlly on the Local Resolver", Bin Zhang, Yu Zhang, Jiankang Yao, Rongwei Yang, Yuming Feng, 2025-05-13, A DNS lookup usually requires the local resolver to start an iterative query process from the DNS root server to the bottom authoritative server. Attacks may occur at any level when querying authoritative servers. If the DNS recursive resolver operator can obtain the IP addresses of the authoritative servers for the queried domain, they may want to query the authoritative server directlly on the local resolver. In such a way, the resolver can start the iterative query process from the designated authoritative server, greatly decreasing the round-trip time, avoiding the attacks on the upper-level and preventing snooping by third parties of requests sent to upper-level authoritative servers. This document shows a technique for quering the designated authoritative server directlly on the local recursive server, at the cost of adding some operational fragility for the operator. "Secure Webhook Token (SWT)", Stephan Knauer, 2025-05-15, The Secure Webhook Token (SWT) is a specialized JSON Web Token (JWT) format designed for securely authorizing and verifying webhook requests. It defines a set of claims to ensure that the token is explicitly tied to webhook events and that its integrity can be reliably validated by the recipient. A key feature of SWT is the introduction of a unique claim, webhook, which encapsulates webhook- specific information, such as the event type. By providing a structured and secure approach to webhook authentication, SWT aims to be a lightweight and flexible solution while maintaining compatibility with typical JWT structures. It is designed with the best practices in mind and may serve as a foundation for future standardization efforts. "Evidence Package Format Specification", Lily Hopkins, Eden Turner, 2025-06-05, Taking evidence is a key part of any 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. "DS support for private DNSSEC algorithms", Mark Andrews, 2025-05-30, Extend the DS digest field of the DS record to identify the private DNSSEC algorithm of the DNSKEY matching the DS record. "Framework for Energy Efficiency Management", Benoit Claise, Luis Contreras, Jan Lindblad, Marisol Amador, Emile Stephan, Qin WU, 2025-06-13, 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. "The Reason for Abandoning the UPA Draft", Aijun Wang, 2025-06-16, [I-D.ietf-lsr-igp-ureach-prefix-announce] (UPA draft) proposes the solution to announce the prefix unreachable information within the IGP domain. It utilizes the LSInfinity concept that is introduced in [RFC2328], without analyzing the dormant and flawed design. The proposal doesn't work even in simple scenario, is based on one flawed feature, lacks the explicit withdrawn procedures and defines some new flags to convey the maintenance information. This document analyzes the above issues, suggests the IETF commuity abandon the UPA draft, replace it with other more comprehensive document [I-D.wang-lsr-prefix-unreachable-annoucement](Founder Draft), to provide the IETF community the more optimal solution. "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability", Ken Huang, Vineeth Narajala, Idan Habler, Akram Sheriff, 2025-05-16, The proliferation of AI agents requires robust mechanisms for secure discovery. This document introduces the Agent Name Service (ANS), a novel architecture based on DNS addressing the lack of a public agent discovery framework. ANS provides a protocol-agnostic registry mechanism that leverages Public Key Infrastructure (PKI) certificates for verifiable agent identity and trust. The architecture features several key innovations: a formalized agent registration and renewal mechanism for lifecycle management; DNS-inspired naming conventions with capability-aware resolution; a modular Protocol Adapter Layer supporting diverse communication standards (A2A, MCP, ACP, etc.); and precisely defined algorithms for secure resolution. This specification describes structured communication using JSON Schema and includes a comprehensive threat analysis. The result is a foundational agent directory service protocol addressing the core challenges of secure discovery and interaction in multi-agent systems, paving the way for future interoperable, trustworthy, and scalable agent ecosystems. "Privacy Preference Declaration for Home Networks", Daniel Smullen, Brian Scriber, 2025-06-09, This document proposes a framework that empowers users to define and enforce privacy policies within their home networks through a Privacy Preference Declaration (PPD) protocol. As connected devices proliferate, this approach enhances user control by enabling user- defined privacy settings for different data types, automatic policy discovery by new devices, and accountability measures such as notifications, network restrictions, or perhaps reporting non- compliance with users' defined preferences to designated authorities. The framework aims to cultivate a privacy-conscious home network environment through clear, enforceable privacy governance. "Privacy Preference Declaration Taxonomy", Daniel Smullen, Brian Scriber, 2025-06-09, This document defines a standardized taxonomy for describing data handling practices of Internet-connected devices within home networks. It complements the Privacy Preference Declaration (PPD) Protocol by providing the necessary vocabulary and semantic structure to represent and reason about data types, purposes, actions, sources, and destinations. This taxonomy supports both machine reasoning and human interpretation and can be implemented using ontological frameworks such as OWL-DL. "The tag-42 profile of CBOR Core", Bumblefudge, Robin Berjon, 2025-05-22, This document defines a strict profile of CBOR Core (CBOR/c) intended for use with the special tag 42. Like the CBOR Core it profiles, "CBOR/c-42" can also be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR/c-42 objects link to one another by hash-based identifiers, deterministic encoding is mandated to verify dereferenced links and encode new ones. This document mainly targets CBOR tool developers and those downstream users who would like to precisely configure their tools. While full support in CBOR tools would be ideal and is already possible in some highly configurable parsing libraries, ALDRs can help close the delta by sidestepping the biggest interoperability stumbling blocks; see Appendix C for details. "Polynomial Commitment Schemes", Ying Lai, 2025-05-22, This document describes the high-level interface of a polynomial commitment scheme (PCS), a cryptographic primitive used in constructing generic zk-SNARKs. A PCS allows a prover to commit to a polynomial, and later attest to its correct evaluation at a given point. Test vectors and reference implementations for popular instantiations are provided in Appendix A. "SCHC Context lifecycle and management", Marion Dumay, 2025-05-23, Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism. SCHC operation is based on a common static Context stored at the two (or more) ends of a communication. As the scope of SCHC becomes broader, the static Context needs to evolve towards a more dynamic Context. This purpose of this document is to initiate a discussion on the lifecycle of a Context. It describes the main steps in the lifecycle of a SCHC Context, and more broadly, it aims at documenting the related Requirements and Terminology for the proper use of SCHC. These goals are in line with the Working Group's objectives, as set out in the Charter: * "Produce an informational document describing how a carried protocol can use SCHC", * "Produce Standard Track documents for SCHC Rule Discovery and Parameter Negotiation", * "Produce Standard Track documents for SCHC Rule Provisioning". "OAuth 2.0 step-up authorization challenge proto", Jeff Lombardo, Alexandre Babeanu, 2025-05-23, It is not uncommon for resource servers to require additional information like details of delegation authorization, or assurance proof of the delegation of authorization mechanism used according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the data and metadata associated with the access token of the current request does not meet its authorization requirements and, further, how to meet them. This document also codifies a taxonomy to guide the client into starting a new request towards the authorization server in order to get issued, if applicable, a new set of tokens matching the requirements. "CORECONF Rule management for SCHC", Ana Minaburo, Laurent Toutain, Corentin Banier, Marion Dumay, 2025-05-24, This document describes how CORECONF management can be applied to SCHC Context. "Considerations for Protective DNS Server Operators", Haixin Duan, Mingxuan Liu, Baojun Liu, Chaoyi Lu, 2025-05-26, Recent research work has delved deeply into a new type of DNS security service, Protective DNS, through various measurement methods, and it has been deployed in multiple DNS providers and even in national ISPs. Protective DNS identifies whether the domain names requested by customers are in the threat intelligence (blocklist) it maintains. For domain names listed in the blocklist, it rewrites the resolution results to secure resources to prevent users from accessing malicious resources, such as malicious servers (IP addresses), etc. This document summarizes the conclusions of these research works and provides specific and practical considerations and suggestions for the deployment and operation of Protective DNS. By following these considerations, Protective DNS service providers can effectively enhance the practicality and security of their services. "DomainKeys Originator Recipient (DKOR)", Dave Crocker, 2025-05-26, DKIM associates a domain name with a message stream, using cryptographic methods, to permit reliable and accurate reputation- oriented analysis of the stream. It is possible for an authorized user to conspire for additional distribution of a message, leveraging the domain name reputation for promoting spam. This is called DKIM Replay. DKOR defines a means of limiting that ability, by associating original addressing information with the message's DKIM signature, to detect distribution beyond the intended recipient. DKOR uses existing DKIM services and only requires implementation of the additional DKOR features by the signer and any receiving site wishing to participate in DKOR services. Other DKIM receivers can successfully process the same DKIM signature without knowledge of DKOR. "EchoPulse: Adaptive Symbolic KEM Framework for Low-Resource Cryptographic Systems", Tom Wartenberg, 2025-05-27, This document introduces EchoPulse, a Key Encapsulation Mechanism (KEM) designed for high efficiency and minimal resource usage, offering adaptive symbolic behavior and built-in resistance to replay and side-channel attacks. EchoPulse aims to serve as a viable lightweight PQC candidate. "KerPass EPHEMSEC One-Time Password Algorithm", Marc Vieuille, 2025-05-30, This document specifies EPHEMSEC, an algorithm for generating one- time passwords (OTPs) and one-time keys (OTKs). Unlike traditional OTP algorithms that rely solely on static shared secrets, EPHEMSEC uses public key cryptography, which simplifies secure deployment on authentication servers. EPHEMSEC also supports binding the generated OTP/OTK to contextual data. When this context is obtained and injected by a trusted agent, the resulting codes can be made resistant to phishing and man-in-the-middle attacks. Finally, EPHEMSEC includes a built-in time synchronization mechanism that embeds a synchronization hint into the generated output. This allows both parties to deterministically derive the same OTP/OTK value without requiring trial-and-error validation, enabling compatibility with protocols such as Password Authenticated Key Exchange (PAKE) and TLS with Pre-Shared Key (TLS-PSK) that require exact secret agreement. "Protocol extension and mechanism for fused service function chain", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Xueshun Wang, Dongping Deng, 2025-05-28, This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. "Architecture and application scenario for fused service function chain", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Xueshun Wang, Jun Gao, 2025-05-28, This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. "Protocol extension and mechanism for fused service function chain", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Xueshun Wang, Dongping Deng, 2025-05-28, This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. "Architecture and application scenario for fused service function chain", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Xueshun Wang, Jun Gao, 2025-05-28, This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. "Challenges in Transporting Sensing Data with Media Over QUIC", Yi Yue, Feile Li, Wei Liu, Chenchen Yang, Arashmid Akhavain, Kuan Zhang, 2025-05-29, 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. "Enhancing Local-Use Domain Name Resolution within Link-Local Scope", LiangYi Gong, Zhiwei Yan, Man Zhang, Kejun Dong, Chun Long, 2025-05-29, Link-local networks such as home Internet of Things (IoT) and industrial Internet of Things are becoming increasingly prosperous, with a large number of small devices deployed in the link-local networks. These devices discover each other through ".local." domain names of DNS-based zero-configuration network protocol. However, the lack of specialized security operations to supervise link-local DNS resolution leads to some security risks. This memo addresses the potential risks associated with the leakage of link-local DNS traffic to external networks, the lack of identity authentication on ".local." domain requests, and the lack of rate-limiting on ".local." domain responses, which poses the leakage of link-local device information and the risk of DDoS attacks. Furthermore, the document proposes a set of best practices and technical solutions to mitigate these risks and ensure that ".local." domain name resolution remains confined within the local network segment. "Media Type Registration for Protocol Buffers", Murray Kucherawy, Warren Kumari, Rob Sloan, 2025-05-29, This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. "Simple namespace-like proposal for JSON using a separator, for the RPP", Stephane Bortzmeyer, 2025-06-01, This document proposes a lightweight convention for namespaces in the JSON payloads of RPP: a registry of namespaces plus the convention to write JSON names as namespace_shortname. It is not intended to be published as a RFC, just to stir discussion. "Root CA Emergency Self-Termination Protocol (RTO-Extension)", Torsten Jahnke, 2025-05-31, This document defines a cryptographically secure mechanism for Root Certificate Authorities to perform emergency self-termination upon compromise detection. Current PKI architecture creates a mathematical impossibility: Root CAs cannot be cryptographically revoked because revocation requires validation from a higher authority, but Root CAs are self-signed with no higher authority. This specification addresses this architectural limitation through game-theoretic analysis where attacker key usage patterns result in compromise detection and bounded attack duration. The mechanism enables Root CA operators to terminate CA validity within hours instead of months while maintaining strict dual-person control. Analysis of historical incidents shows average response times of 180-540 days. This protocol reduces maximum exposure time to 8-72 hours through cryptographic self-termination, providing 74-85% reduction in attack exposure duration based on empirical analysis. "TCP Extended Options", Ron Bonica, Tony Li, 2025-05-30, The TCP header can accommodates 40 octets of TCP options. However, modern applications may require more than 40 octets of TCP Options. Therefore, this document describes an experiment that extends the TCP Options field. If this experiment is successful, it will demonstrate the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility. "Testing Leading Whitespace in Artwork for XML2RFC", Daniel Gillmor, 2025-05-30, XML2RFC should produce uniform whitespace in textual artwork elements. "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Sub-Stacks", Rakesh Gandhi, Tianran Zhou, Zhenqiang Li, 2025-06-02, 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 Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. "Requirements of Fast Notification for Traffic Engineering and Load Balancing", Xuesong Geng, PengFei Huo, Yongqing Zhu, Dan Li, Weiqiang Cheng, Chang Liu, 2025-06-03, This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver near real-time network status updates. FaNTEL enables fast failure and congestion notifications, supporting rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, improving service reliability and performance. "CATALOG Authorization Transparency And Log Overlay for Graph-based DNS", Marc Weidner, 2025-06-03, This document proposes an extension to the Certification Authority Authorization (CAA) DNS Resource Record (RR) that enables the mandatory or optional binding of Certificate Transparency (CT) Log URIs directly within DNS. By embedding CT-Log endpoints in CAA RR, Certification Authorities (CAs) gain a standardized, discoverable mechanism for retrieving preferred and permitted CT-Log endpoint information, thereby enhancing the security and auditability of X.509 TLS certificate issuance. The extension defines the syntax and semantics for a new CAA property tag, *"issuect"*, and introduces a parameter set consisting of _"desc"_, _"critical"_, _"validfrom"_, _"validtill"_, _"cturi"_, _"logid"_, and _"pubkey"_. It outlines validation and processing rules, discusses deployment considerations, privacy implications, and interoperability with existing DNS, CA, and CT infrastructures. Additionally, the draft proposes an MTA-STS-like hardening mechanism, called *CAA-CT-STS*, for the new property to further strengthen the PKI ecosystem. Finally, it introduces the recursive acronym CATALOG (CATALOG Authorization Transparency And Log Overlay for Graph-based DNS) as a mnemonic for the overall extension framework. "JSContact: Optional Unique Identifiers", Robert Stepanek, 2025-06-04, This document redefines the mandatory "uid" property of a Card object to become optional. This is both for using JSContact in other protocols than CardDAV and JMAP for Contacts, as well as to align the semantics of the vCard UID property with JSContact. This is a breaking change, this document introduces version "2.0" to replace the current JSContact version "1.0". "Using TLS Client Authentication with DNS Handles", Phillip Hallam-Baker, 2025-06-04, This is a discussion document prepared for the DANCE Working Group presenting possible convergence between the DNS Handles authentication approach based on OAUTH being used in the ATmosphere and the DANCE approach. User experience and architectural requirements for using TLS Client Authentication in a DNS Handles based environment are discussed. "Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)", Brian Sipos, 2025-06-04, This document defines a protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within a delay-tolerant network (DTN). Security associations are used to amortize the costs of asymmetric-keyed security operations and allow for efficient and high-throughput BPv7 security within a public key infrastructure. "The DIMG (Dual-Image) File Format Specification", Wang HongXing, 2025-06-05, This document specifies the DIMG (Dual-Image) file format, which encapsulates two discrete image blocks within a single file container. The format addresses common inefficiencies in handling front/back documentation scenarios by eliminating redundant file management operations and simplifying data exchange workflows. Security considerations are discussed in Section 7. "Module-Lattice Key Exchange in SSH", Alexander Harrison, Andrew Benhase, Panos Kampanakis, 2025-06-05, This document defines pure post-quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes for use in the SSH Transport Layer Protocol. "Early IANA Registry Creation", Amanda Baber, 2025-06-05, This memo describes the requirements for publishing a registry on the IANA website before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when a Working Group needs to coordinate allocations among multiple documents or with an organization outside the IETF. "MNA for Metadata in SR-MPLS Service Programming", Yao Liu, 2025-06-06, This document defines MPLS Network Action(MNA) encoding to carry metadata in SR service programming with SR-MPLS data plane. "Transition to Full BGPsec Deployment: Transitive-BGPsec is Incompatible with BGPsec", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Yangfei Guo, 2025-06-08, This document elaborates on the reasons why it is unfeasible to reconstruct the native-BGPsec as a transitive approach, such that a BGP update with a correctly signed BGPsec_PATH attribute can traverse legacy areas and afterwards it can still be properly processed by subsequent native-BGPsec speakers. "Registration Protocol for Performance and Diagnostic Metrics", Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, 2025-06-08, This document specifies a registration protocol for use with Performance and Diagnostic Metrics version 2 (PDMv2). This registration process enables endpoints to communicate supported policies and capabilities in advance of measurement sessions, simplifying setup and enhancing security. The protocol defines a set of commands, responses, and message formats, and proposes integration with the Diameter Base Protocol (RFC6733) as the transport and authentication mechanism. "Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing", Xuesong Geng, PengFei Huo, Weiqiang Cheng, Dan Li, Yongqing Zhu, Han Zhengxin, 2025-06-08, Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability. "A Profile for Route Path Authorizations (RPAs)", Yangfei Guo, Xiaoliang Wang, Ke Xu, Zhuotao liu, Li Qi, 2025-06-09, This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). "BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects", Ke Xu, Shenglin Jiang, Yangfei Guo, Xiaoliang Wang, 2025-06-09, The Route Path Authorizations (RPA) is an RPKI object that attests to the complete routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. "Benchmarking Methodology for Computing-aware Traffic Steering", Kehan Yao, Peng Liu, 2025-06-09, 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. "Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography", Aritra Banerjee, Tirumaleswar Reddy.K, 2025-06-09, Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. "Fragmentation Revisited: For What It's Worth", Fred Templin, 2025-06-11, Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. "BIER Payload Label", Zhaohui Zhang, Toerless Eckert, Hooman Bidgoli, Zheng Zhang, 2025-06-09, The BIER Encapsulation RFC8296 specifies that the "Proto" field in the BIER header is set to 1 if an MPLS label stack follows the BIER header and the top of the stack label is a downstream-assigned label, and is set to 2 if the top of stack label is an upstream-assigned label, which is looked up in the context-specific label forwarding table that can be derived from the BIER header. The terms upstream/downstream-assignment are inappropriate to describe the required forwarding for new MPLS label semantics such as SRGB and DCB labels as defined in RFC8402 and RFC9573 respectively. This can result in potentially inconsistent implementation choices causing potential interoperability issues. This document rectifies this situation by changing the IANA BIER Next Protocol Identifier semantic for MPLS code points from their label semantic to the required LFIB in the forwarding plane, hence covering those new type of labels without changing behavior for existing upstream/downstream-assigned labels. "Forwarding Commitment BGP Testbed and Deployment Experience", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, Ziwei Li, Yangfei Guo, 2025-06-10, Forwarding Commitment BGP (FC-BGP) enables the establishment of a secure inter-domain routing system by providing security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. In an effort to enhance the validation of FC-BGP, a prototype implementation of the FC-BGP was developed and an evaluation was conducted on the FITI high-performance IPv6 backbone network. This document reports on the prototype implementation and the results of the evaluation. "Technical Considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT)", Quan Xiong, Jie Liu, 2025-06-10, This document analyses the gaps of the existing transport layer technologies and provides technical considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT). "LEO transport problem statement", Feng Yang, Tina Tsou, 2025-06-10, LSN, Starlink and OneWeb, can provide global Internet connectivity with latency comparable to terrestrial networks, but their fast movement and frequent handovers result in highly dynamic connectivity changes. The fast movement of LSN will introduce frequent handover and varying link delays every few minutes. As the path over LSN varies, TCP cannot tell whether changes in packet loss or RTT are due to path changes or network congestion, thus it might not be able to make proper adjustment. This greatly impact the performance of TCP. "The Fast Software Authenticated Encryption HiAE", Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou, 2025-06-16, This document describes the high throughput authenticated encryption algorithm HiAE designed for new wireless generation 6G and data transmission applications. "Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0", Giuseppe De Marco, Brandon Pitman, 2025-06-12, 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 the possession of public keys, protocol specific metadata and various 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. "Announce Existence of Parent CDS/CSYNC Scanner", Erik Bergstrom, Johan Stenstam, Leon Fernandez, 2025-06-12, 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 [I-D.draft-ietf-dnsop-generalized-notify], 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. "An EAT Profile for Device Attestation", Mathieu Poirier, Thomas Fossati, 2025-06-12, 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. "The HPKE Elligator KEM", Martin Schanzenbach, Pedram Fardzadeh, 2025-06-12, This document contains the GNUnet communicator specification. This document defines the normative wire format of communicator protocols, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNUnet communicators, guide future communicator implementations, and ensure interoperability among implementations including with the pre-existing GNUnet implementation. "MPLS Network Action for Stack Management", Fabian Ihle, Michael Menth, 2025-06-13, The MPLS Network Action (MNA) framework provides a general mechanism for the encoding and processing of network actions and their data. This document introduces a network action to the MPLS Network Action (MNA) framework for stack management operations including MOVE-N-LSE and POP-N-LSE. The MOVE-N-LSE operation elevates a specified number of LSEs within the stack and the POP-N-LSE operation removes a specified number of LSEs. The stack management operations can be used to facilitate various applications. As an example, a mechanism called HBH preservation which reduces the readable label depth (RLD) requirement in nodes is presented. "Signaling MNA Capabilities Using IGP", Fabian Ihle, Xueyan Song, Michael Menth, 2025-06-13, This document defines capabilities of nodes supporting MPLS Network Actions (MNA) and how to signal them using IS-IS and OSPF. The capabilities include the Readable Label Depth (RLD), supported network action opcodes, and the maximum sizes of differently scoped Network Action Sub-stacks (NAS), called the NAS_MLD. For IS-IS and OSPF signaling, sub-TLV encodings based on existing mechanisms to signal node- and link-specific capabilities are leveraged. "Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems", Ken Huang, 2025-06-13, This document specifies extensions to the Entity Attestation Token (EAT) [RFC9248] to support robust, interoperable attestation of capabilities in agentic AI systems. These extensions introduce new claims and guidance for securely asserting agent functional, reasoning, and operational capabilities, as well as their compositional structure and policy constraints. The goal is to enable trustworthy, verifiable, and privacy-respecting capability attestation for autonomous agents in dynamic, decentralized environments. "Extending Certificate Enrollment Protocols for Scalable Agentic AI Identity", Ken Huang, Jerry Huang, 2025-06-13, Agentic AI systems require robust, verifiable identities to operate securely. While traditional certificate enrollment protocols like SCEP and EST can be extended to include remote attestation evidence, performing a full validation for every agent's certificate request presents significant scalability and privacy challenges. This document proposes two distinct, scalable models for integrating attestation into the enrollment lifecycle. The first model leverages Zero-Knowledge Proofs (ZKP) to provide private, efficient, and continuous attestation. The second model uses a one-time, high- assurance bootstrapping process to establish a trusted host environment, which is then authorized to endorse certificate requests for the agents it runs. Both models enable high-assurance identity for AI agents while addressing the performance bottlenecks of naive per-enrollment verification. "ICMP Error Handling in SRv6 based VPN Networks", Zafar Ali, Krzysztof Szarkowicz, Sijo Joy, 2025-06-15, The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). "Priority-based Flow Control SID in SRv6", Zheng Ruan, Mengyao Han, Han Zhengxin, liuy619@chinaunicom.cn, 2025-06-15, 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. "Updates to OAuth 2.0 Security Best Current Practice", Tim Wuertele, Pedram Hosseyni, Kaixuan Luo, Adonis Fung, 2025-06-16, This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. "Proxy for Congestion Notification", Xiao Min, 2025-06-16, 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 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. "Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages.", Klaus Frank, 2025-06-16, This document aims to standardize the validation of mutual TLS authentication between servers (server-to-server). It outlines recommended validation flows as well as provides practical design recommendations. Basically the EKU id-kp-clientAuth and id-kp- serverAuth get more precisely defined to represent their common understanding by issuing CAs and browsers. id-kp-clientAuth aka. "TLS WWW client authentication" SHOULD mean authentication of a natural or legal entity. id-kp-serverAuth aka. "TLS WWW server authetnication" SHOULD mean authentication of a device. When two id- kp-clientAuth certificates are used this means E2E authentication between two users. Where as two id-kp-serverAuth certificates being used means server-to-server authentication. And one user and one server certificate within one TLS connection means client-to-server (or technically also server-to-client). The term "TLS-Client" SHOULD no longer be used and mean the party sending the initial package while establishing a TLS connection. This helps to avoid design issues moving forward as currently some people thought TLS-Client auth was only ever used in "client-to-server" and never within "server-to-server" context. Which sparked the demand for this document to begin with to keep server-to-server auth with public trusted certificates working. Network Time Protocols (ntp) ---------------------------- "Roughtime", Watson Ladd, Marcus Dansarie, 2025-04-22, This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. "Network Time Protocol Version 5", Miroslav Lichvar, Tal Mizrahi, 2025-04-10, This document describes version 5 of the Network Time Protocol (NTP). "NTP Over PTP", Miroslav Lichvar, 2025-02-19, This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) which encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers which can timestamp only PTP messages and enables delay corrections in PTP transparent clocks. "NTS4PTP - Network Time Security for the Precision Time Protocol", Martin Langer, Rainer Bermbach, 2025-02-12, This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. It also provides measures against known attack vectors targeting PTP. Network Virtualization Overlays (nvo3) -------------------------------------- "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi, 2025-06-03, This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. Web Authorization Protocol (oauth) ---------------------------------- "OAuth 2.0 for Browser-Based Applications", Aaron Parecki, Philippe De Ryck, David Waite, 2025-03-03, This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. "The OAuth 2.1 Authorization Framework", Dick Hardt, Aaron Parecki, Torsten Lodderstedt, 2025-05-28, 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. "Selective Disclosure for JWTs (SD-JWT)", Daniel Fett, Kristina Yasuda, Brian Campbell, 2025-05-29, This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. "Cross-Device Flows: Security Best Current Practice", Pieter Kasselman, Daniel Fett, Filip Skokan, 2025-01-06, This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Oliver Terbu, Daniel Fett, Brian Campbell, 2025-05-28, 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. "OAuth 2.0 Attestation-Based Client Authentication", Tobias Looker, Paul Bastian, Christian Bormann, 2025-03-03, This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. "Token Status List", Tobias Looker, Paul Bastian, Christian Bormann, 2025-05-23, This specification defines a mechanism, 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. "Transaction Tokens", Atul Tulshibagwale, George Fletcher, Pieter Kasselman, 2025-03-03, Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to initiate transactions with protected user identity an authorization context throughout the call chain of the workloads required to complete the request. "OAuth Identity and Authorization Chaining Across Domains", Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell, 2025-02-27, This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. "OAuth 2.0 for First-Party Applications", Aaron Parecki, George Fletcher, Pieter Kasselman, 2025-04-24, 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. "Updates to Audience Values for OAuth 2.0 Authorization Servers", Michael Jones, Brian Campbell, Chuck Mortimore, 2025-04-23, This specification updates the requirements for audience values for tokens whose audience is an OAuth 2.0 authorization server to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. Oblivious HTTP Application Intermediation (ohai) ------------------------------------------------ "Chunked Oblivious HTTP Messages", Tommy Pauly, Martin Thomson, 2025-04-25, This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. Open Specification for Pretty Good Privacy (openpgp) ---------------------------------------------------- "Post-Quantum Cryptography in OpenPGP", Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler, 2025-06-11, 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. "Persistent Symmetric Keys in OpenPGP", Daniel Huigens, 2025-01-30, This document defines new algorithms for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for authentication with hash-based message authentication codes (HMAC). This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. "OpenPGP Key Replacement", Daphne Shaw, Andrew Gallagher, 2025-02-03, This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "PCAP Capture File Format", Guy Harris, Michael Richardson, 2025-03-03, This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. "Terminal Access Controller Access-Control System Plus over TLS 1.3 (TACACS+ over TLS)", Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota, 2025-05-11, The Terminal Access Controller Access-Control System Plus (TACACS+) protocol provides device administration for routers, network access servers, and other networked computing devices via one or more centralized TACACS+ servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC 8907. "Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX)", Thomas Graf, Benoit Claise, Alex Feng, 2025-04-05, This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay on the OAM transit and decapsulating nodes. "Link-Layer Types for PCAP-related Capture File Formats", Guy Harris, Michael Richardson, 2025-04-25, This document describes a set of PCAP-related LinkType values and creates an IANA registry for those values. "PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson, 2025-03-03, This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. "A Data Manifest for Contextualized Telemetry Data", Benoit Claise, Jean Quilbeuf, Diego Lopez, Ignacio Martinez-Casanueva, Thomas Graf, 2025-06-11, Network platforms use Model-driven 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 in order 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. "Export of UDP Options Information in IP Flow Information Export (IPFIX)", Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-07-22, This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. "A YANG Data Model and RADIUS Extension for Policy-based Network Access Control", Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King, 2025-03-20, 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. "A Common YANG Data Model for Attachment Circuits", Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu, 2025-01-23, The document specifies a common attachment circuits (ACs) YANG model, which is designed to be reusable by other models. This design is meant to ensure consistent AC structures among models that manipulate ACs. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu, 2025-01-23, Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a 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 is referred to as "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a YANG service model for managing bearers over which ACs are established. "A Network YANG Data Model for Attachment Circuits", Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu, 2025-01-23, This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). "A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits", Mohamed Boucadair, Richard Roberts, Samier Barguil, Oscar de Dios, 2025-01-23, This document defines a YANG data model, referred to as the "AC Glue" model, to augment the Layer 2/3 Service Model (LxSM) and Layer 2/3 Network Model (LxNM) with references to attachment circuits (ACs). The AC Glue model enables a provider to associate Layer 2/3 VPN services (LxVPNs) with the underlying AC infrastructure, thereby facilitating consistent provisioning and management of new or existing ACs in conjunction with LxVPN services. Specifically, by introducing an integrated approach to AC and LxVPN management, this model supports Attachment Circuit-as-a-Service (ACaaS) and provides a standardized mechanism for aligning AC/VPN requests with the network configurations required to deliver them. "Information and Data Models for Packet Discard Reporting", John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair, 2025-05-01, This document defines an information model and a corresponding YANG data model for packet discard reporting. The information model provides an implementation-independent framework for classifying packet loss to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this framework for network elements. "Guidelines for Characterizing "OAM"", Carlos Pignataro, Adrian Farrel, Tal Mizrahi, 2025-06-11, 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 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 RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. "IP Flow Information Export (IPFIX) Alternate-Marking Information Elements", Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Yongqing Zhu, Mauro Cociglio, 2025-05-22, This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. "Export of GTP-U Information in IP Flow Information Export (IPFIX)", Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Vyasraj Satyanarayana, 2025-04-15, This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. "A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)", Mohamed Boucadair, Bo Wu, 2025-05-05, This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. "A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests", Luis Contreras, Victor Lopez, 2025-01-29, 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. "Publishing End-Site Prefix Lengths", Oliver Gasser, Randy Bush, Massimo Candela, Russ Housley, 2025-06-13, This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. "Applying COSE Signatures for YANG Data Provenance", Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz, Sofia Garcia, 2025-05-09, 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. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. Pseudowire And LDP-enabled Services (pals) ------------------------------------------ "Private Line Emulation over Packet Switched Networks", Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Chris Brown, 2025-02-12, This document expands the applicability of virtual private wire services (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over packet switched networks (PSN). Path Computation Element (pce) ------------------------------ "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Dhruv Dhody, Vishnu Beeram, Jonathan Hardwick, Jeff Tantsura, 2025-01-26, This document defines a YANG data model for the management of the Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2025-04-16, 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. "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths", Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2025-02-13, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", Mike Koldychev, Siva Sivabalan, Samuel Sidor, Colby Barth, Shuping Peng, Hooman Bidgoli, 2025-04-04, A Segment Routing (SR) Policy is an ordered list of instructions, called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). "PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution.", Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou, 2025-01-06, The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. "PCEP Extension for Stateful Inter-Domain Tunnels", Olivier Dugeon, Julien Meuric, Young Lee, Daniele Ceccarelli, 2025-03-03, This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the PCE toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, new PCEP communication Protocol (PCEP) Capability, new PCE Errors Type and new PCE Notifications Type. "PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra, 2025-04-09, Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one 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 PCEP mechanisms are meant 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. "Procedures for Communication between Stateful Path Computation Elements", Haomian Zheng, Stephane Litkowski, Siva Sivabalan, Cheng Li, 2025-05-29, The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. In some use cases, inter-PCE stateful communication can bring additional resiliency in the design, for instance, when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use cases and also the procedures to prevent computational loops. "PCEP extensions for P2MP SR Policy", Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan, 2025-02-19, 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. "PCEP Extension for Layer 2 (L2) Flow Specification", Dhruv Dhody, Adrian Farrel, Zhenbin Li, 2025-03-02, The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. "Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP).", Samuel Sidor, Zoey Rose, Shaofu Peng, Shuping Peng, Andrew Stone, 2025-05-20, 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). This document proposes an approach for informing PCEP peers about the SR-Algorithm associated with each SID used, as well as signaling a specific SR-Algorithm as a constraint to the Path Computation Element (PCE). The mechanisms for specifying an SR-Algorithm constraint allow for refined path computations that meet specific operational needs, such as low-latency or high-bandwidth paths based primarily on operator-defined criteria using Flexible Algorithms. Additionally, this document updates RFC 8664 and RFC 9603 to allow encoding of SR-Algorithm of specific SID in Explicit Route Object (ERO) subobjects. "Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP)", Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor, 2025-02-12, 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). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. "Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT", Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola, 2025-01-03, 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 PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. "A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)", Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor, 2025-04-21, 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). "Path Computation Element Protocol (PCEP) Extension for Color", Balaji Rajagopalan, Vishnu Beeram, Shaofu Peng, Mike Koldychev, Gyan Mishra, 2025-02-26, Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute. "PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution.", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2025-02-19, The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. Each path is specified as a set of "segments" encoded in the header of each packet as a list of Segment Identifiers (SIDs). This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in the SRv6 (SR in IPv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID allocation and distribution. "Updates for PCEPS: TLS Connection Establishment Restrictions", Dhruv Dhody, Sean Turner, Russ Housley, 2024-01-09, Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data. "PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang, 2025-06-04, Tree Engineering for Bit Index Explicit Replication (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE). "Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies", Samuel Sidor, Praveen Maheshwari, Andrew Stone, Luay Jalil, Shuping Peng, 2025-05-05, Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. "Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions", Quan Xiong, Shaofu Peng, Fengwei Qin, Junfeng Zhao, 2025-04-17, Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. "PCEP extensions for Distribution of Link-State and TE Information", Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra, 2025-04-21, 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. "Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space", Cheng Li, Hang Shi, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2025-04-29, 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. "Update to Automatic Bandwidth Adjustment procedure of Stateful PCE", Shuping Peng, Dhruv Dhody, Rakesh Gandhi, 2025-06-01, Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. "PCEP Extensions to support BFD parameters", Orly Bachar, Marina Fizgeer, 2025-02-11, This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. "PCEP Operational Clarification", Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni, Andrew Stone, 2025-04-29, This document clarifies certain aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Path Computation Element mailing list (pce@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/pce/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-pce/draft-ietf-pce-operational. Privacy Enhancements and Assessments Research Group (pearg) ----------------------------------------------------------- "Guidelines for Performing Safe Measurement on the Internet", Iain Learmonth, Mallory Knodel, Gurshabad Grover, 2025-03-18, Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the internet, it can present risks to user privacy and safety. This document describes briefly those risks and proposes guidelines for ensuring that internet measurements can be carried out safely, with examples. Protocols for IP Multicast (pim) -------------------------------- "Segment Routing Point-to-Multipoint Policy", Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2025-05-23, Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. A SR P2MP Policy consists of Candidate Paths (CP) which define the topology of P2MP tree instances in each Candidate Path. A P2MP tree instance is instantiated by a set of Replication segments. This document specifies the architecture, signaling, and procedures for SR P2MP Policies within Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) dataplane. It defines the P2MP Policy construct, the roles of the root and leaf nodes, Candidate Paths and and how P2MP trees using Replication Segments are instantiated and maintained. Additionally, it describes the required extensions for Path Computation Element (PCE) to support P2MP path computation and provisioning. "PIM Join/Prune Attributes for LISP Environments using Underlay Multicast", Vengada Govindan, Stig Venaas, 2025-02-21, This document specifies an update to the PIM Receiver RLOC Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059. "P2MP Policy Ping", Hooman Bidgoli, Dan Voyer, Rishabh Parekh, Zhaohui Zhang, 2025-02-05, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of a set of candidate paths that connects the Root of the Tree to a set of Leaves. A candidate path can contain two path instances for global optimization purposes. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs). "IGMP and MLD Snooping Yang Module Extension for L2VPN", Hongji Zhao, Xufeng Liu, Yisong Liu, Mahesh Sivakumar, Anish Peter, 2025-03-24, Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. "Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate (TI-LFA) Fast Reroute", Yisong Liu, Mike McBride, Zheng Zhang, Jingrong Xie, Changwang Lin, 2025-04-08, This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides fast reroute protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of fast reroute mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure. "Multicast Lessons Learned from Decades of Deployment Experience", Dino Farinacci, Lenny Giuliano, Mike McBride, Nils Warnke, 2025-01-30, 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. "Zeroconf Multicast Address Allocation Problem Statement and Requirements", Nathan Karstens, Dino Farinacci, Mike McBride, 2025-02-22, This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. "Updates to Dynamic IPv6 Multicast Address Group IDs", Nathan Karstens, Dino Farinacci, Mike McBride, 2025-05-08, Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). "Group Address Allocation Protocol (GAAP)", Dino Farinacci, Mike McBride, 2025-02-27, This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. "Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service", Steve Deering, Toerless Eckert, 2025-01-29, This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. "Zero-Configuration Assignment of IPv6 Multicast Addresses", Nathan Karstens, Dino Farinacci, Mike McBride, 2025-03-15, Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. "Yang Data Model for EVPN multicast", Hongji Zhao, Yisong Liu, Xufeng Liu, Mani Panchanathan, Mahesh Sivakumar, 2025-02-24, This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. "Deterministic Upstream Neighbor Selection for PIM Joins", Bill Fenner, Santosh Kumar, Stig Venaas, 2025-05-08, In densely interconnected networks, a PIM node may have many choices as to what upstream neighbor to send a JOIN message to, for a given source and group. This document describes a mechanism for multiple nodes (e.g., leaf nodes in a data center) to pick the same upstream node (e.g., spine node) to avoid redundant traffic flows. Privacy Preserving Measurement (ppm) ------------------------------------ "Distributed Aggregation Protocol for Privacy Preserving Measurement", Tim Geoghegan, Christopher Patton, Brandon Pitman, Eric Rescorla, Christopher Wood, 2025-04-29, There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. "Task Binding and In-Band Provisioning for DAP", Shan Wang, Christopher Patton, 2025-05-05, An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. Post-Quantum Use In Protocols (pquip) ------------------------------------- "Post-Quantum Cryptography for Engineers", Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth, 2025-05-19, The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. "Hybrid signature spectrums", Nina Bindel, Britta Hale, Deirdre Connolly, Flo D, 2025-01-09, This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums "Adapting Constrained Devices for Post-Quantum Cryptography", Tirumaleswar Reddy.K, Dan Wing, Ben S, Kris Kwiatkowski, 2025-06-15, This document offers guidance on incorporating Post-Quantum Cryptography (PQC) into resource-constrained devices, including IoT devices and lightweight Hardware Security Modules (HSMs), which operate under tight limitations on compute power, memory, storage, and energy. It highlights the role of the Root of Trust in enabling secure operations, including seed-based key generation to reduce the need for persistent storage, efficient approaches to managing ephemeral keys, and methods for offloading cryptographic tasks in low-resource environments. Additionally, it examines how PQC affects firmware update mechanisms in such constrained systems. Privacy Pass (privacypass) -------------------------- "Privacy Pass Token Expiration Extension", Scott Hendrickson, Christopher Wood, 2025-01-24, This document describes an extension for Privacy Pass that allows tokens to encode expiration information. "Batched Token Issuance Protocol", Raphael Robert, Christopher Wood, Thibault Meunier, 2025-02-02, This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. "The PrivateToken HTTP Authentication Scheme Extensions Parameter", Scott Hendrickson, Christopher Wood, 2025-05-27, This document specifies new parameters for the "PrivateToken" HTTP authentication scheme. This purpose of these parameters is to negotiate and carry extensions for Privacy Pass protocols that support public metadata. "Privacy Pass Issuance Protocols with Public Metadata", Scott Hendrickson, Christopher Wood, 2025-05-27, This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. QUIC (quic) ----------- "QUIC-LB: Generating Routable QUIC Connection IDs", Martin Duke, Nick Banks, Christian Huitema, 2025-03-03, QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. "qlog: Structured Logging for Network Protocols", Robin Marx, Luca Niccolini, Marten Seemann, Lucas Pardue, 2025-03-17, 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. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). "QUIC event definitions for qlog", Robin Marx, Luca Niccolini, Marten Seemann, Lucas Pardue, 2025-03-17, 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. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). "HTTP/3 qlog event definitions", Robin Marx, Luca Niccolini, Marten Seemann, Lucas Pardue, 2025-03-17, 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. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). "QUIC Acknowledgment Frequency", Jana Iyengar, Ian Swett, Mirja Kuehlewind, 2025-02-28, 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. "Multipath Extension for QUIC", Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind, 2025-04-23, This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. "QUIC Stream Resets with Partial Delivery", Marten Seemann, Kazuho Oku, 2025-06-14, QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. "QUIC Address Discovery", Marten Seemann, Christian Huitema, 2025-03-03, Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. "Extended Key Update for QUIC", Yaroslav Rosomakho, Hannes Tschofenig, 2025-05-10, This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. RADIUS EXTensions (radext) -------------------------- "Operational Considerations for RADIUS and TLS-PSK", Alan DeKok, 2025-01-21, This document provides implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the RADIUS/UDP to RADIUS/TLS. "(Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS", Jan-Frederik Rieckers, Stefan Winter, 2025-05-27, 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. "Deprecating Insecure Practices in RADIUS", Alan DeKok, 2025-05-25, RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The recent publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give recommendations for practices which increase both security and privacy. "Reverse Change of Authorization (CoA) in RADIUS/TLS", Alan DeKok, Vadim Cargatser, 2025-05-27, This document defines a "reverse Change of Authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. "Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS)", Margaret Cullen, Alan DeKok, Mark Donnelly, Josh Howlett, 2025-03-03, This document describes extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to allow participants in a multi- hop RADIUS proxy fabric to check the status of a remote RADIUS authentication realm, gain visibility into the path that a RADIUS request will take across the RADIUS proxy fabric, and mitigate or prevent RADIUS proxy loops. Remote ATtestation ProcedureS (rats) ------------------------------------ "Reference Interaction Models for Remote Attestation Procedures", Henk Birkholz, Michael Eckel, Wei Pan, Eric Voit, 2025-02-26, This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. "Attestation Event Stream Subscription", Henk Birkholz, Eric Voit, Wei Pan, 2025-01-08, This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). In RATS, the Conceptional Messages defined can potentially be subscribed to. Specifically, the YANG module defined in this document augments the YANG module for TPM-based Challenge-Response based Remote Attestation (CHARRA) to allow for subscription to the Conceptual Message type Evidence. Additionally, this document provides the methods and means to define additional Event Streams for other Conceptual Messages than Evidence as illustrated in the RATS Architecture, e.g., Attestation Results, Reference Values, or Endorsements. The module defined requires at least one TPM 1.2, TPM 2.0, or equivalent hardware implementation providing the same protected capabilities as TPMs to be available in the Attester the YANG server is running on. "Direct Anonymous Attestation for the Remote Attestation Procedures Architecture", Henk Birkholz, Christopher Newton, Liqun Chen, Dave Thaler, 2025-03-03, This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. "Attestation Results for Secure Interactions", Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata, 2025-02-06, This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. "Concise Reference Integrity Manifest", Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan, 2025-03-03, 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. "RATS Endorsements", Dave Thaler, Henk Birkholz, Thomas Fossati, 2025-03-03, In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. "RATS Conceptual Messages Wrapper (CMW)", Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze, 2025-05-30, Section 8 of RFC 9334 defines "conceptual messages" as abstract messages exchanged by RATS roles such as Evidence, Attestation Results, Endorsements, and Reference Values. This document defines a "conceptual message" wrapper (CMW) format for any RATS conceptual message and describes a collection type that aggregates one or more CMWs into a single message. In addition, this document specifies a corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, and an X.509 extension. These mechanisms enable the embedding of enveloped conceptual messages into CBOR-based protocols, web APIs, and PKIX formats and protocols. Moreover, a Media Type and a CoAP Content- Format are defined for transporting CMWs over HTTP, MIME, CoAP, and other Internet protocols. "Epoch Markers", Henk Birkholz, Thomas Fossati, Wei Pan, Carsten Bormann, 2025-04-11, 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, nonce-like structures, and a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. "EAT Measured Component", Simon Frost, Thomas Fossati, Hannes Tschofenig, 2025-03-03, The term "measured component" refers to an object within the attester's target environment whose state can be inspected and digested. A digest is typically 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. "Remote Posture Assessment for Systems, Containers, and Applications at Scale", Kathleen Moriarty, Monty Wiseman, Alexander Stein, Chandra Nelogal, 2025-05-16, This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. "PKIX Key Attestation", Mike Ounsworth, Jean-Pierre Fiset, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith, 2025-03-03, This document specifies a vendor-agnostic format for attesting to the protection properties of a symmetric or asymmetric cryptographic key within a hardware cryptographic module to support applications such as providing evidence to a Certification Authority that a key is being protected in accordance with the requested certificate profile, or that HSMs can perform key import and maintain the private key protection properties in a robust way even when migrating keys across HSM vendors. This specification includes a format for requesting a key attestation containing certain attributes. This specification is called "PKIX Attestation" because it is designed to be easy to implement on top of a code base that already supports X.509 and PKCS#11 data models. "EAT Attestation Results", Thomas Fossati, Eric Voit, Sergei Trofimov, Henk Birkholz, 2025-04-07, This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. "Evidence Transformations", Fabrizio Damato, Andrew Draper, Ned Smith, 2025-04-08, 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. Registration Protocols Extensions (regext) ------------------------------------------ "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses", Mario Loffredo, Gavin Brown, 2025-04-10, This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. "Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)", Dmitry Belyavsky, James Gould, Scott Hollenbeck, 2025-05-19, The Extensible Provisioning Protocol (EPP) does not natively support internationalized email addresses because the specifications for these addresses did not exist when EPP was developed. This document describes a command-response extension that adds support for associating an additional email address with an EPP contact object. That additional email address can be either an internationalized email address or an all-ASCII address. "Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search", Tom Harrison, Jasdip Singh, 2025-06-04, The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and ASNs, which are provided by RIRs via their Whois services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. "Registration Data Access Protocol (RDAP) Extension for Geofeed Data", Jasdip Singh, Tom Harrison, 2025-06-05, This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses. "Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, William Carroll, Gautam Akiwate, 2025-03-13, The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency. "Extensions Parameter for the RDAP Media Type", Andy Newton, Jasdip Singh, 2025-04-09, This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. "RDAP Extensions", Andy Newton, Jasdip Singh, Tom Harrison, 2025-04-29, This document describes and clarifies the usage of extensions in RDAP. "Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data", Jasdip Singh, Andy Newton, 2025-05-21, The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). "Extensible Provisioning Protocol (EPP) Transport over HTTPS", Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould, 2025-04-29, This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). "Extensible Provisioning Protocol (EPP) Transport over QUIC", Jiankang Yao, Hongtao Li, Man Zhang, Dan Keathley, James Gould, 2025-02-25, This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. Routing In Fat Trees (rift) --------------------------- "SRIFT: Segment Routing in Fat Trees", Zhaohui Zhang, Jeff Tantsura, Jordan Head, 2025-01-06, This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic. "RIFT Key/Value TIE Structure and Processing", Jordan Head, Tony Przygienda, 2025-05-27, 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. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Root-initiated Routing State in RPL", Pascal Thubert, Rahul Jadhav, Michael Richardson, 2025-03-11, The Routing Protocol for Low-Power and Lossy Networks (RPL, RFC 6550) enables data packet routing along a Destination-Oriented Directed Acyclic Graph . However, the default route establishment mechanism relies on hop-by-hop forwarding along the DODAG, which may not always provide optimal routing efficiency. This document introduces the concept of DAO Projection, a mechanism that allows a RPL root or an external controller to install optimized routes within the RPL domain. DAO Projections enable the creation of optimized unicast or multicast routes that do not strictly follow the DODAG structure, thereby improving routing efficiency, reliability, availability, and resource utilization in the RPL domain. The document specifies two types of projected routes—storing mode and non-storing mode projections—and outlines the signaling procedures necessary to establish, maintain, and remove these routes. This document extends RFC 6550, RFC 6553, and RFC 8138. "Supporting Asymmetric Links in Low Power Networks: AODV-RPL", Charles Perkins, S.V.R Anand, Satish Anamalamudi, Bing Liu, 2025-03-02, Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. "Controlling Secure Network Enrollment in RPL networks", Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki, 2025-03-03, [RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. "RNFD: Fast border router crash detection in RPL", Konrad Iwanicki, 2025-03-10, By and large, a correct operation of a network running RPL (the IPv6 routing protocol for low-power and lossy networks) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies RNFD (the root node failure detector), an extension to RPL that expedites border router crash detection by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Options for synchronizing this state among different nodes, and the coordination algorithm itself. RESTful Provisioning Protocol (rpp) ----------------------------------- "RESTful Provisioning Protocol (RPP) - Requirements", Maarten Wullink, Pawel Kowalik, 2025-06-02, This document describes the requirement for the development of the RESTful Provisioning Protocol (RPP). RFC Series Working Group (rswg) ------------------------------- "RFC Editor Model (Version 3)", Paul Hoffman, Alexis Rossi, 2025-05-12, This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280. This document updates RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and 8729. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/ (https://datatracker.ietf.org/edwg/rswg/documents/). There is a repository for this draft at https://github.com/ paulehoffman/9280-updates (https://github.com/ paulehoffman/9280-updates). "SVGs in RFCs", Alexis Rossi, Nevil Brownlee, Jean Mahoney, Martin Thomson, 2025-06-13, This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from RFC 7996 and removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs. Routing Area Working Group (rtgwg) ---------------------------------- "BGP Prefix Independent Convergence", Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra, 2025-04-20, In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. "Fast failure detection in VRRP with Point to Point BFD", Nitish Gupta, Aditya Dogra, Colin Docherty, Jeff Tantsura, 2025-01-31, This document describes how Point to Point Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Active Router failure in the Virtual Router Redundancy Protocol (VRRP). "A YANG Data Model for ARP", Feng Zheng, Bo Wu, Robert Wilton, Fan Zhang, Yongqing Zhu, Xiaojian Ding, 2025-01-01, 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. "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno, 2025-03-17, The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on industry-standard BGP to address the ATN/IPS requirements. "Topology Independent Fast Reroute using Segment Routing", Ahmed Bashandy, Stephane Litkowski, Clarence Filsfils, Pierre Francois, Bruno Decraene, Dan Voyer, 2025-02-12, This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. "Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices", Linda Dunbar, Andrew Malis, Christian Jacquenet, Mehmet Toy, Kausik Majumdar, 2025-01-17, This document describes a set of network-related problems enterprises face at the time of writing this document (2025) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. "SRv6 Path Egress Protection", Tao He, Zhibo Hu, Huaimo Chen, Mehmet Toy, Chang Cao, 2025-05-27, TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. "Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)", Greg Mirsky, Jeff Tantsura, Gyan Mishra, 2025-02-13, This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568. "Multi-segment SD-WAN via Cloud DCs", Kausik Majumdar, Linda Dunbar, Venkit Kasiviswanathan, Ashok Ramchandra, Aseem Choudhary, 2025-02-18, This document describes a method for SD-WAN Customer Premises Equipment (CPEs) to use GENEVE encapsulation (RFC8926) to transport IPsec-encrypted packets across a Cloud Backbone without requiring decryption at Cloud Gateways (GWs). In this approach, SD-WAN CPEs encapsulate IPsec-encrypted payloads within GENEVE headers and forward them to their nearest Cloud GWs. These Cloud GWs then steer the encrypted traffic through the Cloud Backbone while preserving its confidentiality, ensuring seamless transport to the destination Cloud GWs. The egress Cloud GWs subsequently deliver the original IPsec- encrypted payloads to the receiving CPEs. This mechanism enables the Cloud Backbone to interconnect multiple SD-WAN segments efficiently, eliminating the need for Cloud GWs to decrypt and re-encrypt payloads, thus enhancing the performance. "Destination/Source Routing", David Lamparter, Anton Smirnov, Jen Linkova, Shu Yang, Mingwei Xu, 2025-03-21, This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC8200] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously. "A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)", Acee Lindem, Xufeng Liu, Athanasios Kyparlis, Ravi Parikh, Mingui Zhang, 2025-06-12, This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. "YANG Data Model for IPv6 Neighbor Discovery", Fan Zhang, Yongqing Zhu, Bo Wu, Jiayuan Hu, 2025-03-01, 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), SEcure Neighbor Discovery (SEND), and Secure ND Proxy. Secure Asset Transfer Protocol (satp) ------------------------------------- "Secure Asset Transfer (SAT) Interoperability Architecture", Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna, 2025-06-15, This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. "Secure Asset Transfer Protocol (SATP) Core", Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac, 2025-06-06, This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. Source Address Validation in Intra-domain and Inter-domain Networks (savnet) ---------------------------------------------------------------------------- "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)", Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery, 2025-03-15, 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. "Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements", Dan Li, Jianping Wu, Lancheng Qin, Mingqing(Michael) Huang, Nan Geng, 2025-05-13, 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. "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", Dan Li, Jianping Wu, Libin Liu, Mingqing(Michael) Huang, Kotikalapudi Sriram, 2025-03-15, 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. "Intra-domain Source Address Validation (SAVNET) Architecture", Dan Li, Jianping Wu, Lancheng Qin, Nan Geng, Li Chen, 2025-04-13, This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way. "Inter-domain Source Address Validation (SAVNET) Architecture", Dan Li, Li Chen, Nan Geng, Libin Liu, Lancheng Qin, 2025-03-03, This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. "General Source Address Validation Capabilities", Mingqing(Michael) Huang, Weiqiang Cheng, Dan Li, Nan Geng, Li Chen, 2025-03-16, 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. Static Context Header Compression (schc) ---------------------------------------- "Static Context Header Compression (SCHC) Architecture", Alexander Pelov, Pascal Thubert, Ana Minaburo, 2025-02-06, This document defines the SCHC architecture. "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo, 2025-03-03, 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/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. "Static Context Header Compression and Fragmentation over networks prone to disruptions", Edgar Ramos, Lorenzo Corneo, Ana Minaburo, Rodrigo Munoz-Lara, Sandra Cespedes, 2025-06-04, This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. "Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6)", Dominique Barthel, Laurent Toutain, 2025-06-13, This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages. "Options representation in SCHC YANG Data Models", Quentin Lampin, Ana Minaburo, Marco Tiloca, Laurent Toutain, 2025-04-14, 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. "Options representation in SCHC YANG Data Models", Quentin Lampin, Ana Minaburo, Marco Tiloca, Laurent Toutain, 2025-05-15, 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. System for Cross-domain Identity Management (scim) -------------------------------------------------- "SCIM Profile for Security Event Tokens", Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber, 2025-06-02, This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. "Cursor-based Pagination of SCIM Resources", Matt Peterson, Danny Zollner, Anjali Sehgal, 2025-05-09, This document defines additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM implementations that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. "Device Schema Extensions to the SCIM model", Muhammad Shahzad, Hassan Iqbal, Eliot Lear, 2025-05-20, The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. "System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements", Paulo Correia, Pamela Dingle, 2025-01-20, This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. Supply Chain Integrity, Transparency, and Trust (scitt) ------------------------------------------------------- "An Architecture for Trustworthy and Transparent Digital Supply Chains", Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker, 2025-05-08, 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 proposes a scalable architecture for single-issuer signed statement transparency applicable to any supply chain. It ensures flexibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. "SCITT Reference APIs", Henk Birkholz, Jon Geater, 2025-03-03, This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. Standard Communication with Network Elements (scone) ---------------------------------------------------- "Standard Communication with Network Elements (SCONE) Protocol", Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar, 2025-05-06, On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. "Standard Communication with Network Elements (SCONE) Protocol", Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar, 2025-05-28, On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. Security Area (sec) ------------------- "Push And Pull Based Security Event Token (SET) Delivery", Atul Tulshibagwale, Apoorva Deshpande, Aaron Parecki, 2025-04-17, This specification defines how multiple Security Event Tokens (SETs) can be delivered and received to and by an intended recipeint using HTTP POST over TLS or WebSocket binding. This specification enabled following two use cases - * In situations where a transmitter of Security Event Tokens (SETs) to a network peer is also a receiver of SETs from the same peer, it is helpful to have an efficient way of sending and receiving SETs in one HTTP transaction. In many cases, such as when using the OpenID Shared Signals Framework (SSF), the situation where each entity is both a transmitter and receiver is getting increasingly common. * In situations where a transmitter of Security Event Tokens (SETs) wants to transmit multiple SETs to the reciever in a single HTTP call. Using current mechanisms such as "Push-Based Delivery of Security Event Tokens (SETs) Using HTTP" or "Poll-Based Delivery of Security Event Tokens (SETs) Using HTTP" both require two or more HTTP connections to exchange SETs between peers. This is inefficient due to the latency of setting up each communication. This specification enables mutiple events to be transmitted in bi-directional transmission and reception of multiple SETs in one HTTP connection, and enables them to do so over a single HTTP or WebSocket binding. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://sgnl- ai.github.io/pushpull/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tulshibagwale-saag- pushpull-delivery/. Source for this draft and an issue tracker can be found at https://github.com/SGNL-ai/pushpull. SIDR Operations (sidrops) ------------------------- "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Job Snijders, Kotikalapudi Sriram, 2025-03-23, 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. "A Profile for Autonomous System Provider Authorization", Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison, 2025-01-06, This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA 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 upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Randy Bush, Rob Austein, 2025-06-11, 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. "Human Readable Validate ROA Payload Notation", Tim Bruijnzeels, Ties de Kock, Oliver Borchert, Di Ma, 2025-03-03, 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", Tim Bruijnzeels, Oliver Borchert, Di Ma, Ties de Kock, 2025-03-03, 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). "Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA)", Job Snijders, Ben Cartwright-Cox, 2025-05-22, ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. "Revision of the RPKI Validation Algorithm", Job Snijders, Ben Maddison, 2025-05-08, This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6487. This document updates RFC 9582. This document obsoletes RFC 8360. "RPKI Manifest Number Handling", Tom Harrison, George Michaelson, Job Snijders, 2025-06-16, The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. "Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations", Kotikalapudi Sriram, Job Snijders, Doug Montgomery, 2025-06-16, The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. "RPKI Publication Server Best Current Practices", Tim Bruijnzeels, Ties de Kock, Frank Hill, Tom Harrison, 2025-03-03, 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. "Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions", Job Snijders, Ben Maddison, Theo Buehler, 2025-05-22, This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions. This document updates RFC 6487. "A Profile for Mapping Origin Authorizations (MOAs)", Chongfeng Xie, Guozhen Dong, Xing Li, Geoff Huston, Di Ma, 2025-04-10, This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object, it provides a means that the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. When receiving the MOA objects from the relying partie, PE device can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. "Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors", Job Snijders, Theo Buehler, Ties de Kock, 2025-02-12, A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document proposes a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. Session Initiation Protocol Core (sipcore) ------------------------------------------ "SIP Call-Info Parameters for Rich Call Data", Chris Wendt, Jon Peterson, 2025-04-21, This document specifies a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the originating party in order to provide to the terminating party a description of the caller (including details about the reason for the session). RCD includes information about the caller beyond the telephone number such as a calling name, a logo, photo, or jCard object representing the caller, which can help the called party decide how to handle the session request. This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon". "Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses", Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske, 2025-04-30, The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. "Updates to SIPREC correcting Metadata Media Type", Dan Mongrain, 2025-05-02, The SIP-based Media Recording (SIPREC) protocol is defined by both Session Initiation Protocol (SIP) Recording Metadata (RFC 7865) and Session Recording Protocol (RFC 7866). Unfortunately, both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFCs registered the new media type. This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and registers the new media type. Structured Email (sml) ---------------------- "Structured Email", Hans-Joerg Happel, 2025-02-07, This document specifies how a machine-readable version of the content of email messages can be added to those messages. "Structured vacation notices", Hans-Joerg Happel, 2025-01-10, This document describes a machine-readable format for vacation notices in email messages. It is supposed to be used in conjunction with conventional, human-readable vacation notices. Structured vacation notices are based on the forthcoming "structured email" specifications defined in [I-D.ietf-sml-structured-email-01] and related drafts. Secure Patterns for Internet CrEdentials (spice) ------------------------------------------------ "SPICE SD-CWT", Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy, 2025-03-02, This document describes a data minimization technique for use with CBOR Web Token (CWT). The approach is based on Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE). "Use Cases for SPICE", Michael Prorock, Brent Zundel, 2025-03-17, 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", Brent Zundel, Pamela Dingle, Michael Jones, 2025-04-15, This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace. "OpenID Connect standard claims registration for CBOR Web Tokens", Beltram Maldant, 2025-04-23, This document registers OpenId Connect standards claims already used in JSON Web Tokens for CBOR Web Tokens. Source Packet Routing in Networking (spring) -------------------------------------------- "Service Programming with Segment Routing", Francois Clad, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano, 2025-02-23, This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. "Introducing Resource Awareness to SR Segments", Jie Dong, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, 2025-05-08, This document describes the mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. A list of resource-aware SIDs can be used to allow an SR Policy to use a specific set of network resources, and a group of resource-aware SIDs can be used to represent a virtual network with a specific set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). "YANG Data Model for Segment Routing Policy", Syed Raza, Tarik Saleh, Shunwan Zhuang, Dan Voyer, Muhammad Durrani, Satoru Matsushima, Vishnu Beeram, 2025-05-25, 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. "Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)", Cheng Li, Weiqiang Cheng, Mach Chen, Dhruv Dhody, Yongqing Zhu, 2025-04-03, 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. "Segment Routing based Network Resource Partition (NRP) for Enhanced VPN", Jie Dong, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, 2025-06-10, Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on 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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". Segments can represent topological or service based instructions. Segments can further be associated with a set of network resources used for executing the instruction. Such segments are called resource-aware segments. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote, 2025-05-09, Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the Simple Two-Way Active Measurement Protocol (STAMP) 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 SR paths (including SR Policies and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. "Compressed SRv6 Segment List Encoding (CSID)", Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Bruno Decraene, Francois Clad, 2025-02-06, Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. "Circuit Style Segment Routing Policy", Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone, 2025-06-16, This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "circuit-style" SR Policy (CS-SR Policy). "Distribute SRv6 Locator by DHCP", Weiqiang Cheng, Ruibo Han, Changwang Lin, Dan Voyer, Geng Zhang, 2025-04-30, 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. "Path MTU (PMTU) for Segment Routing (SR) Policy", Shuping Peng, Dhruv Dhody, Ketan Talaulikar, Gyan Mishra, 2025-03-03, This document defines the Path MTU (PMTU) for Segment Routing (SR) Policy (called SR-PMTU). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU for SR Policy including the link MTU collection, the SR-PMTU computation, the SR-PMTU enforcement, and the handling behaviours on the headend. "Segment Routing IPv6 Security Considerations", Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont, 2025-05-05, 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 for Inter-Layer Network Programming", Liuyan Han, Jie Dong, Minxue Wang, Ran Chen, Zongpeng Du, 2025-04-30, The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. Secure Shell Maintenance (sshm) ------------------------------- "Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512", Markus Friedl, Jan Mojzis, Simon Josefsson, 2025-05-16, This document describe a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. "SSH Agent Protocol", Damien Miller, 2025-06-12, 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. "Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305", Damien Miller, Simon Tatham, Simon Josefsson, 2025-03-17, This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. Note This document is UNFINISHED. Before publication as an RFC, it must no longer contain any instance of the string "FIXME", which is used to mark where required information has not yet been added. "PQ/T Hybrid Key Exchange in SSH", Panos Kampanakis, Douglas Stebila, Torben Hansen, 2025-04-14, This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant the Module-Lattice- Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. These methods are defined for use in the SSH Transport Layer Protocol. Secure Telephone Identity Revisited (stir) ------------------------------------------ "OCSP Usage for Secure Telephone Identity Certificates", Jon Peterson, Sean Turner, 2025-02-28, When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. "PASSporT Extension for Rich Call Data", Chris Wendt, Jon Peterson, 2023-06-05, This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. "Out-of-Band STIR for Service Providers", Jon Peterson, 2025-03-03, The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a Session Initiation Protocl (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. "Connected Identity for STIR", Jon Peterson, Chris Wendt, 2024-10-21, The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. Software Updates for Internet of Things (suit) ---------------------------------------------- "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Oyvind Ronningstad, 2025-05-28, This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. "Encrypted Payloads in SUIT Manifests", Hannes Tschofenig, Russ Housley, Brendan Moran, David Brown, Ken Takayama, 2025-03-19, This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. "Secure Reporting of Update Status", Brendan Moran, Henk Birkholz, 2025-03-03, 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. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. 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. "Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests", Brendan Moran, Ken Takayama, 2025-03-17, This specification describes extensions to the SUIT manifest format. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. "SUIT Manifest Extensions for Multiple Trust Domains", Brendan Moran, Ken Takayama, 2025-03-03, This specification describes extensions to the SUIT Manifest format for use in deployments with multiple trust domains. A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. "Strong Assertions of IoT Network Access Requirements", Brendan Moran, Hannes Tschofenig, 2025-03-03, The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two. "Cryptographic Algorithm Recommendations for Software Updates of Internet of Things Devices", Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto, 2025-06-14, This document specifies cryptographic algorithm profiles to be used with the Software Updates for Internet of Things (suit) manifest. These profiles define mandatory-to-implement algorithms to ensure interoperability. Thing-to-Thing (t2trg) ---------------------- "Guidance on RESTful Design for Internet of Things Systems", Ari Keranen, Matthias Kovatsch, Klaus Hartke, 2025-04-23, 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). "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Michael Richardson, 2025-05-28, This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. "Terminology and processes for initial security setup of IoT devices", Mohit Sethi, Behcet Sarikaya, Dan Garcia-Carrillo, 2025-03-27, 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. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "TCP Extended Data Offset Option", Joseph Touch, Wesley Eddy, 2025-05-31, TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 9293 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. "More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP", Bob Briscoe, Mirja Kuehlewind, Richard Scheffenegger, 2025-03-10, Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more Accurate ECN (AccECN) feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is additionally exploited to feed back the IP-ECN field received during the TCP connection establishment. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes. "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Marcelo Bagnulo, Bob Briscoe, 2025-04-21, This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone. "Proportional Rate Reduction for TCP", Matt Mathis, Neal Cardwell, Yuchung Cheng, Nandita Dukkipati, 2025-06-12, This document specifies a standards-track version of the Proportional Rate Reduction (PRR) algorithm that obsoletes the experimental version described in RFC6937. PRR regulates the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm. "TCP ACK Rate Request Option", Carles Gomez, Jon Crowcroft, 2025-05-30, TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. "Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs", Yepeng Pan, 2025-04-13, 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. Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------- "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2025-05-29, 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. "A YANG Data Model for requesting path computation", Italo Busi, Sergio Belotti, Oscar de Dios, Anurag Sharma, Yan Shi, 2025-02-13, There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation 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-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. "Traffic Engineering (TE) and Service Mapping YANG Data Model", Young Lee, Dhruv Dhody, Giuseppe Fioccola, Qin WU, Daniele Ceccarelli, Jeff Tantsura, 2025-01-29, 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. "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Young Lee, Dhruv Dhody, Ricard Vilalta, Daniel King, Daniele Ceccarelli, 2025-04-21, 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. "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli, 2025-02-25, 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 "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing", Daniel King, John Drake, Haomian Zheng, Adrian Farrel, 2024-08-28, Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. "A YANG Data Model for the RFC 9543 Network Slice Service", Bo Wu, Dhruv Dhody, Reza Rokui, Tarek Saad, John Mullooly, 2025-05-09, This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. "Realizing Network Slices in IP/MPLS Networks", Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng, 2025-03-02, 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 relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. "Common YANG Data Types for Traffic Engineering", Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin, 2025-02-21, 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", Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra, 2025-03-02, 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 Application in 3GPP 5G End-to-End Network Slice", Xuesong Geng, Luis Contreras, Reza Rokui, Jie Dong, Ivan Bykov, 2025-03-03, Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. "A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies", Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras, 2025-04-03, Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks. "IETF Network Slice Controller and its Associated Data Models", Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, 2025-03-03, 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. "YANG Data Models for Network Resource Partitions (NRPs)", Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng, 2025-03-02, RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. "A YANG Data Model for MPLS-TE Topology", Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Rakesh Gandhi, 2025-03-17, This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. "Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases", Italo Busi, Xufeng Liu, Igor Bryskin, Tarek Saad, Oscar de Dios, 2025-04-14, This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". "Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management", Samier Barguil, Luis Contreras, Victor Lopez, Oscar de Dios, Mohamed Boucadair, 2025-02-04, This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. "IETF Network Slice Topology YANG Data Model", Xufeng Liu, Luis Contreras, Sergio Belotti, Aihua Guo, Italo Busi, 2025-03-17, An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. Trusted Execution Environment Provisioning (teep) ------------------------------------------------- "HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication", Dave Thaler, 2023-03-27, The Trusted Execution Environment Provisioning (TEEP) Protocol is used to manage code and configuration data in a Trusted Execution Environment (TEE). This document specifies the HTTP transport for TEEP communication where a Trusted Application Manager (TAM) service is used to manage code and data in TEEs on devices that can initiate communication to the TAM. "Trusted Execution Environment Provisioning (TEEP) Protocol", Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto, 2025-03-03, This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. "TEEP Usecase for Confidential Computing in Network", Meiling Chen, Penglin Yang, Li Su, Ting Pang, 2025-05-28, Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC (Multi-access Computing) and other scenarios to use confidential computing in network. Transport Layer Security (tls) ------------------------------ "TLS Encrypted Client Hello", Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher Wood, 2025-06-14, This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). "A Flags Extension for TLS 1.3", Yoav Nir, 2025-03-15, A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. "Hybrid key exchange in TLS 1.3", Douglas Stebila, Scott Fluhrer, Shay Gueron, 2025-01-14, Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. "The Transport Layer Security (TLS) Protocol Version 1.3", Eric Rescorla, 2025-02-17, This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. "Return Routability Check for DTLS 1.2 and DTLS 1.3", Hannes Tschofenig, Achim Kraus, Thomas Fossati, 2025-06-16, This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. "IANA Registry Updates for TLS and DTLS", Joseph Salowey, Sean Turner, 2025-06-16, This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. "Deprecating Obsolete Key Exchange Methods in TLS 1.2", Carrick Bartle, Nimrod Aviram, 2024-09-03, This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. "A well-known URI for publishing service parameters", Stephen Farrell, Rich Salz, Benjamin Schwartz, 2025-04-03, 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. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too. "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2025-06-16, To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR). "TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key", Russ Housley, 2025-06-02, This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). "Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3", David Benjamin, Andrei Popov, 2025-05-12, 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. "The SSLKEYLOGFILE Format for TLS", Martin Thomson, Yaroslav Rosomakho, Hannes Tschofenig, 2025-06-09, A format that supports logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data. "TLS 1.2 is in Feature Freeze", Rich Salz, Nimrod Aviram, 2025-04-03, Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. "TLS Key Share Prediction", David Benjamin, 2025-03-03, This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. "Extended Key Update for Transport Layer Security (TLS) 1.3", Hannes Tschofenig, Michael Tuexen, Tirumaleswar Reddy.K, Steffen Fries, Yaroslav Rosomakho, 2025-03-03, The Transport Layer Security (TLS) 1.3 specification provides forward secrecy by utilizing an ephemeral key exchange during the initial handshake. Forward secrecy ensures that even if an attacker later obtains a party's long-term private key, past encrypted sessions cannot be decrypted. This protects against adversaries who record encrypted conversations in the hope of decrypting them later. TLS 1.3 also includes a Key Update mechanism, allowing cryptographic keys to be refreshed during an ongoing session. However, this update does not establish new forward-secret key material. While this is generally not an issue for short-lived sessions, it can pose a security risk for long-lived connections, such as those in industrial IoT or telecommunication networks, where an attacker could compromise application traffic secrets after the initial handshake. Earlier versions of TLS supported session renegotiation, a mechanism that allowed peers to establish new cryptographic parameters within an existing session. This included the ability to update the originally used long-term keys (certificates) with renewed credentials. However, due to security vulnerabilities, the renegotiation mechanism was modified via RFC 5746 and later removed entirely in TLS 1.3, leaving a gap in TLS's ability to refresh cryptographic material securely. This specification introduces an extended key update mechanism that supports forward secrecy, forcing attackers to continuously exfiltrate key material throughout the session to decrypt the entire conversation. "Large Record Sizes for TLS and DTLS with Reduced Overhead", John Mattsson, Hannes Tschofenig, Michael Tuexen, 2025-05-28, TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead. "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Eric Rescorla, Hannes Tschofenig, Nagendra Modadugu, 2024-12-14, 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. "TLS Trust Anchor Identifiers", Robert Beck, David Benjamin, Devon O'Brien, Kyle Nekritz, 2025-05-14, This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency. "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3", Kris Kwiatkowski, Panos Kampanakis, Bas Westerbaan, Douglas Stebila, 2025-03-23, This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). "ML-KEM Post-Quantum Key Agreement for TLS 1.3", Deirdre Connolly, 2025-04-16, This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement. "Use of ML-DSA in TLS 1.3", Tim Hollebeek, Sophie Schmieg, Bas Westerbaan, 2025-05-16, This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. Transport and Services Working Group (tsvwg) -------------------------------------------- "Transport Options for UDP", Joseph Touch, C. Heard, 2025-03-16, Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram. "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services", Greg White, Thomas Fossati, Ruediger Geib, 2025-06-03, This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] "Operational Guidance on Coexistence with Classic ECN during L4S Deployment", Greg White, 2025-03-17, This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. "DCCP Extensions for Multipath Operation with Multiple Addresses", Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson, 2025-04-29, Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience. Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets, vehicles) and residential home gateways that maintain simultaneous connections to distinct network types, such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency- sensitive applications with varying requirements for reliability and in-order delivery. This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths. "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2025-02-20, This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required. "User Ports for Experiments", Joseph Touch, 2025-05-18, This document defines user ports for experiments using transport protocols. It describes the use of experiment identifiers to enable shared use of these user ports. It also updates RFC 4727 to recommend the use of these experimental identifiers for the system ports for experiments in the same manner. "Convergence of Congestion Control from Retained State", Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema, 2025-05-23, This document specifies a cautious method for IETF transports that enables fast startup of CC for a wide range of connections. It reuses a set of computed CC 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 CC 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 Careful Resume impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig, 2025-04-21, This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895. "Configuring UDP Sockets for ECN for Common Platforms", Martin Duke, 2024-12-19, 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. "Quic Logging for Convergence of Congestion Control from Retained State", Ana Custura, Gorry Fairhurst, 2025-05-26, This document specifies a logging format for a cautious method for Careful Resume when using the IETF quic transport protocol. It defines the logging format for qlog. Time-Variant Routing (tvr) -------------------------- "TVR (Time-Variant Routing) Requirements", Daniel King, Luis Contreras, Brian Sipos, Li Zhang, 2025-03-03, 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. "YANG Data Model for Scheduled Attributes", Yingzhen Qu, Acee Lindem, Eric Kinzie, Don Fedyk, Marc Blanchet, 2025-04-22, The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. "Using ALTO for exposing Time-Variant Routing information", Luis Contreras, 2025-03-03, Network operations can require time-based, scheduled changes in nodes, links, adjacencies, etc. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can assist, as an off-path mechanism, on the exposure of such predicted changes to both internal and external applications then anticipating the occurrence of routing changes. This document describes how ALTO helps in that purpose. Using TLS in Applications (uta) ------------------------------- "TLS/DTLS 1.3 Profiles for the Internet of Things", Hannes Tschofenig, Thomas Fossati, Michael Richardson, 2025-05-05, 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. 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/thomas-fossati/draft-tls13-iot. "New Protocols Using TLS Must Require TLS 1.3", Rich Salz, Nimrod Aviram, 2025-04-14, TLS 1.3 use is widespread, it has had comprehensive security proofs, and it improves both security and privacy over TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. This document updates RFC9325 and discusses post-quantum cryptography and the security and privacy improvements over TLS 1.2 as a rationale for that update. IPv6 Operations (v6ops) ----------------------- "Neighbor Discovery Considerations in IPv6 Deployments", XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, Nick Buraglio, 2025-05-26, The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than 20 RFCs. There is a need to track these issues and solutions in a single document. To that aim, this document summarizes the published ND issues and then describes how all these issues originate from three causes. Addressing the issues is made simpler by addressing the causes. This document also analyzes the mitigation solutions and demonstrates that isolating hosts into different subnets and links can help to address the three causes. Guidance is provided for selecting a suitable isolation method to prevent potential ND issues. "Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service", Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Thomas Graf, 2025-04-04, 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. "IPv6 CE Routers LAN DHCPv6 Prefix Delegation", Timothy Winters, 2025-05-22, This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes that were delegated to a IPv6 CE router. This document updates RFC 7084. "464XLAT Customer-side Translator (CLAT): Node Recommendations", Jen Linkova, Tommy Jensen, 2025-03-17, 464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions. "Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)", David Lamparter, Jen Linkova, 2025-03-21, This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. "IPv6-Mostly Networks: Deployment and Operations Considerations", Nick Buraglio, Ondrej Caletka, Jen Linkova, 2025-03-03, 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", Gabor Lencse, Jordi Martinez, Patton, Timothy Winters, 2025-03-03, 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. "Prefer use of RFC8781 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis", Nick Buraglio, Tommy Jensen, Jen Linkova, 2025-02-25, On networks providing IPv4-IPv6 translation (NAT64, RFC7915), hosts and other endpoints might need to know the IPv6 prefix used for translation (the NAT64 prefix). While RFC7050 defined a DNS64-based prefix discovery mechanism, more robust methods have since emerged. This document provides updated guidelines for NAT64 prefix discovery, deprecating the RFC7050 approach in favor of modern alternatives (e.g., RFC8781) except where those are unavailable. Virtualized Conversations (vcon) -------------------------------- "The JSON format for vCon - Conversation Data Container", Daniel Petrie, Thomas McCarthy-Howe, 2025-03-19, A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) WebTransport (webtrans) ----------------------- "The WebTransport Protocol Framework", Victor Vasiliev, 2025-02-25, 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", Alan Frindell, Eric Kinnear, Victor Vasiliev, 2025-03-03, WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote 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", Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie, 2025-03-16, 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. Workload Identity in Multi System Environments (wimse) ------------------------------------------------------ "Workload Identity in a Multi System Environment (WIMSE) Architecture", Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig, 2025-03-02, The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. "WIMSE Workload to Workload Authentication", Brian Campbell, Joe Salowey, Arndt Schwenkschuster, Yaron Sheffer, 2025-05-19, 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. "Workload Identity Practices", Arndt Schwenkschuster, Benedikt Hofmann, Hannes Tschofenig, Edoardo Giordano, Yaroslav Rosomakho, 2025-03-03, The use of the OAuth 2.0 framework in container orchestration systems poses challenges, particularly in managing credentials such as client_id and client_secret, which can be complex and prone to errors. To address this, the industry has shifted towards a federation-based approach where credentials of the underlying workload platform are used as assertions towards an OAuth authorization server, leveraging the Assertion Framework for OAuth 2.0 Client Authentication [RFC7521], specifically [RFC7523]. This specification describes a meta flow in Section 3.1, gives security recommendations in Section 4 and outlines concrete patterns in Appendix A. It referes to existing industry practices that are mainly built on top of OAuth. It may not be in line with the (currently work in progress) WIMSE architecture [I-D.ietf-wimse-arch] and other protocols, such as [I-D.ietf-wimse-s2s-protocol]. Web and Internet Transport (wit) -------------------------------- "Shared Brotli Compressed Data Format", Jyrki Alakuijala, Thai Duong, Evgenii Kliuchnikov, Zoltan Szabadka, Lode Vandevenne, 2025-02-13, This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window and a container format to brotli (RFC 7932). Shared dictionaries and large window support allow significant compression gains compared to regular brotli. This document updates RFC 7932.