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 2024-03-19 08:05:33 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription", Pascal Thubert, 2023-11-10, This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address; the document updates RPL (RFC 6550, RFC 6553) to add a new Non-Storing Multicast Mode and a new support for anycast addresses in Storing and Non-Storing Modes. This document extends RFC 9010 to enable the 6LR to inject the anycast and multicast addresses in RPL. "Transmission of SCHC-compressed packets over IEEE 802.15.4 networks", Carles Gomez, Ana Minaburo, 2024-02-28, 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, Zhe Lou, Peng Liu, Rong Long, Kiran Makhijani, Pascal Thubert, 2024-03-01, 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 static, the location of the nodes is fixed, and the connection between the nodes is also rather stable. This specifications describes the PASA architecture, along with PASA address allocation, forwarding mechanism, header format design, and IPv6 interconnection support. "IPv6 Neighbor Discovery Prefix Registration", Pascal Thubert, 2024-02-13, This document updates IPv6 Neighbor Discovery [RFC4861] and the 6LoWPAN extensions [RFC8505][RFC8928] 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 prefix registration also provides a protocol-independent interface for the node to request neighbor router(s) to redistribute the prefix to the larger routing domain using their specific routing protocols. This document extends RPL [RFC6550][RFC6553][RFC9010] to enable the 6LR to inject the registered prefix in RPL. IPv6 Maintenance (6man) ----------------------- "IPv6 Hop-by-Hop Options Processing Procedures", Robert Hinden, Gorry Fairhurst, 2024-02-25, This document specifies procedures for how IPv6 Hop-by-Hop options are processed in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use in the Internet. When published, this document updates RFC8200. "Limits on Sending and Processing IPv6 Extension Headers", Tom Herbert, 2023-12-18, This specification defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers, thereby increasing the feasibility of deployment 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 Partition (NRP) Information in IPv6 Extension Header", Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma, Gyan Mishra, 2024-02-20, Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction and evolvement 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 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 specifies a new IPv6 Hop-by-Hop option to carry the NRP related information in data packets, 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. "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", Brian Carpenter, Stuart Cheshire, Robert Hinden, 2023-07-02, This document describes how the zone identifier of an IPv6 scoped address, defined as in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax and Internationalized Resource Identifier specifications (RFC 3986, RFC 3987) accordingly, and obsoletes RFC 6874. "SRv6 Segment Identifiers in the IPv6 Addressing Architecture", Suresh Krishnan, 2024-02-15, The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as the underlying forwarding plane. Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs. "IPv6 Query for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, 2023-10-23, This document describes the application of the mechanism of discovering IOAM capabilities, described in RFC 9359 "Ping Enabled 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, 2023-11-20, This document presents an architecture 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 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. "Preference for IPv6 ULAs over IPv4 addresses in RFC6724", Nick Buraglio, Tim Chown, Jeremy Duncan, 2024-01-02, When [RFC6724] was published it defined an address selection algorithm along with a default policy table, and noted a number of examples where that policy table might benefit from adjustment for specific scenarios. It also noted that it is important for implementations to provide a way to change the default policies as more experience is gained. This update draws on several years of operational experience to refine RFC 6724 further, with particular emphasis on preference for the use of ULA addresses over IPv4 addresses and the addition of mandatory support for Rule 5.5. The update also demotes the preference for 6to4 addresses. The changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. "The IPv6 Compact Routing Header (CRH)", Ron Bonica, Yuji Kamite, Andrew Alston, Daniam Henriques, Luay Jalil, 2024-03-18, This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, can be addressed with access control lists. Finally, this document encourages replication of the experiment. "Signalling DHCPv6 Prefix Delegation Availability to Hosts", Lorenzo Colitti, Jen Linkova, Xiao Ma, David Lamparter, 2024-03-17, This document defines a "P" flag in the Prefix Information Option of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that clients do not use the prefix provided in the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use that delegated prefix to form addresses. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Key Provisioning for Group Communication using ACE", Francesca Palombini, Marco Tiloca, 2024-01-16, This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. "Key Management for OSCORE Groups in ACE", Marco Tiloca, Jiye Park, Francesca Palombini, 2023-03-06, This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that 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. "Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)", Francesca Palombini, Cigdem Sengul, Marco Tiloca, 2024-03-04, 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. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, 2024-03-04, 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, 2024-03-04, 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. "Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework", Marco Tiloca, Francesca Palombini, Sebastian Echeverria, Grace Lewis, 2023-06-02, This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. "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, 2024-03-04, 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 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, 2024-03-04, This document specifies public-key certificate enrollment procedures protected with lightweight application-layer security protocols suitable for Internet of Things (IoT) deployments. The protocols leverage payload formats defined in Enrollment over Secure Transport (EST) and existing IoT standards including the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR), and the CBOR Object Signing and Encryption (COSE) format. "Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, 2024-01-14, 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 entity 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. "Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework", Marco Tiloca, Goeran Selander, 2024-03-04, This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the Authorization Server can use for uploading an access token to a Resource Server on behalf of the Client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the Authorization Server. Third, it amends two of the requirements on profiles of the framework. Finally, it deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads. For such error responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles of ACE 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, 2024-03-04, 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "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, 2024-01-11, 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, 2024-02-08, 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) Device Attestation Extension", Brandon Weeks, 2024-02-22, This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. "Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names", Q Misell, 2024-02-27, 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) Scoped DNS Challenges", Antonios Chariton, Amir Omidi, James Kasten, Fotis Loukos, Stanislaw Janikowski, 2024-02-19, This document outlines a new challenge for the ACME protocol, enabling an ACME client to answer a domain control validation challenge from an ACME server using a DNS resource linked to the ACME Account ID. This allows multiple systems or environments to handle challenge-solving for a single domain. Adaptive DNS Discovery (add) ---------------------------- "Establishing Local DNS Authority in Validated Split-Horizon Environments", Tirumaleswar Reddy.K, Dan Wing, Kevin Smith, Benjamin Schwartz, 2023-12-06, When split-horizon DNS is deployed by a network, certain domains can be resolved authoritatively by the network-provided DNS resolver. DNS clients that are not configured to use this resolver can use it, but only to resolve these domains. This specification defines a mechanism for domain owners to inform clients about local resolvers that are authorized to answer authoritatively for certain subdomains. "DNS Resolver Information", Tirumaleswar Reddy.K, Mohamed Boucadair, 2024-02-29, This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How such an information is then used by DNS clients is out of the scope of this document. 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. "The ALTO Transport Information Publication Service", Kai Gao, Roland Schott, Y. Yang, Lauren Delwiche, Lachlan Keller, 2024-01-03, The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource one at a time. ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly, concurrently (non-blocking) request (pull) specific incremental updates using native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)", Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk, 2024-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. "Information Distribution over GRASP", Sheng Jiang, Bing Liu, Xun Xiao, Artur Hecker, Xiuli Zheng, Yanyan Zhang, 2024-02-12, This document specifies experimental extensions to the GRASP protocol to enable information distribution capabilities. The extension has two aspects: 1) new GRASP messages and options; 2) processing behaviors on the nodes. With these extensions, the GRASP would have following new capabilities which make it a sufficient tool for general information distribution: 1) Pub-Sub model of information processing; 2) one node can actively sending data to another, without GRASP negotiation procedures; 3) selective flooding mechanism to allow the ASAs control the flooding scope. This document updates RFC8990, the GeneRic Autonomic Signaling Protocol (GRASP)[RFC8990]. "Join Proxy for Bootstrapping of Constrained Network Elements", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2023-11-06, This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge and Registrar by a stateless/stateful constrained Join Proxy. The constrained Join Proxy is a mesh neighbor of the Pledge and can relay a DTLS session originating from a Pledge with only link-local addresses to a Registrar which is not a mesh neighbor of the Pledge. This document defines a protocol to securely assign a Pledge to a domain, represented by a Registrar, using an intermediary node between Pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". An enrolled Pledge can act as a constrained Join Proxy. "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael Richardson, 2023-08-24, Bootstrapping Remote Secure Key Infrastructures 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 to help the device. This document extends the new device behaviour so that if no local infrastructure is available, such as in a home or remote office, that the device can use a well defined "call-home" mechanism to find the operator maintained infrastructure. To this, 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. "JWS signed Voucher Artifacts for Bootstrapping Protocols", Thomas Werner, Michael Richardson, 2023-08-29, [TODO: I-D.draft-ietf-anima-rfc8366bis] defines a digital artifact called voucher as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS. In addition to explaining how the format is created, 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, 2024-03-04, This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the domain CA. "A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services", Sheng Jiang, Joanna Dang, Zongpeng Du, 2023-09-24, This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types ofnetwork resources. "A Voucher Artifact for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma, 2024-03-04, 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, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", David von Oheimb, Steffen Fries, Hendrik Brockhaus, 2024-03-01, This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995). It supports alternative certificate enrollment protocols, such as CMP, that use authenticated self-contained signed objects for certification messages. This offers the following advantages. The origin of requests and responses can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where and when to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. Applications and Real-Time Area (art) ------------------------------------- "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", John Klensin, Asmus Freytag, 2020-07-13, 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. "WebP Image Format", James Zern, Pascal Massimino, Jyrki Alakuijala, 2024-03-18, This document defines the WebP image format and registers a media type supporting its use. Automatic SIP trunking And Peering (asap) ----------------------------------------- "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2023-12-16, 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, 2024-02-28, 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. 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. // The present revision (-18) adds security considerations, a few // editorial cleanups, discusses JSON pointer encodings, and adds // sockets to the CDDL for easier future extension. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus Flodman, Danny Hong, Jonathan Lennox, 2021-06-10, This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. "Video Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas Nandakumar, 2024-03-04, This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec- specific information. "RTP Payload Format for Essential Video Coding (EVC)", Shuai Zhao, Stephan Wenger, Youngkwon Lim, 2023-12-20, This document describes an RTP payload format for the Essential Video Coding (EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was developed by the Moving Picture Experts Group (MPEG). The RTP payload format allows for the packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets. The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec", Dan Hanson, MikeFaller, Keith Maver, 2024-02-14, This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an application layer protocol that provides end-to-end capability exchange, packetization/de-packetization of media, reliable transport, and payload encryption. SCIP handles packetization/de-packetization of the encrypted media and acts as a tunneling protocol, treating SCIP payloads as opaque octets to be encapsulated within RTP payloads prior to transmission or decapsulated on reception. SCIP payloads are sized to fit within the maximum transmission unit (MTU) when transported over RTP thereby avoiding fragmentation. SCIP transmits encrypted traffic and does not require the use of Secure RTP (SRTP) for payload protection. SCIP also provides for reliable transport at the application layer, so it is not necessary to negotiate RTCP retransmission capabilities. To establish reliable communications using SCIP over RTP, it is important that middle boxes avoid parsing or modifying SCIP payloads. Because SCIP payloads are confidentiality and integrity protected and are only decipherable by the originating and receiving SCIP devices, modification of the payload by middle boxes would be detected as an integrity failure in SCIP devices, resulting in retransmission and/or communication failure. Middle boxes do not need to parse the SCIP payloads to correctly transport them. Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and filtering of SCIP payloads by middle boxes would likely lead to ossification of the evolving SCIP protocol. "RTP over QUIC (RoQ)", Joerg Ott, Mathis Engelbart, Spencer Dawkins, 2024-03-04, 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). It also discusses how to leverage state from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets and how to implement congestion control and rate adaptation without relying on RTCP feedback. "RTP Payload Format for Visual Volumetric Video-based Coding (V3C)", Lauri Ilola, Lukasz Kondrad, 2024-03-18, This memo describes an RTP payload format for visual volumetric video-based coding (V3C) [ISO.IEC.23090-5]. A V3C bitstream is composed of V3C units that contain V3C video sub-bitstreams, V3C atlas sub-bitstreams, or a V3C parameter set. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The RTP payload format for V3C atlas sub-bitstreams is described by this memo. 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, 2023-10-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. "H.265 Profile for WebRTC", Bernard Aboba, Philipp Hancke, 2024-01-24, RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, similar guidance is needed for browsers considering support for the H.265 codec, whose RTP payload format is defined in RFC 7798. "RTP Payload Format for SFrame", Peter Thatcher, 2023-11-07, This document describes the RTP payload format of SFrame. "RTP Payload Format for sub-codestream latency JPEG 2000 streaming", Pierre-Anthony Lemieux, David Taubman, 2023-11-17, 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 codestream can be emitted before the entire codestream is available. Audio/Video Transport Extensions (avtext) ----------------------------------------- "The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2017-07-02, This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. Babel routing protocol (babel) ------------------------------ "YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark, 2021-09-20, This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. "Delay-based Metric Extension for the Babel Routing Protocol", Baptiste Jonglez, Juliusz Chroboczek, 2024-01-15, This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower latency links over higher latency ones. BGP Enabled ServiceS (bess) --------------------------- "Optimized Ingress Replication Solution for Ethernet VPN (EVPN)", Jorge Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi, 2022-01-25, Network Virtualization Overlay networks using Ethernet VPN (EVPN) as their control plane may use Ingress Replication or PIM (Protocol Independent Multicast)-based trees to convey the overlay Broadcast, Unknown unicast and Multicast (BUM) traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the Network Virtualization Overlay core network. Ingress Replication avoids the dependency on PIM in the Network Virtualization Overlay network core. While Ingress Replication provides a simple multicast transport, some Network Virtualization Overlay networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of Ingress Replication trees. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2021-11-18, This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. "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 Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2024-03-04, Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. "EVPN VPWS Flexible Cross-Connect Service", Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Sami Boutros, Jorge Rabadan, 2022-10-24, This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as flexible cross-connect service. After a description of the rationale for this new service type, the solution to deliver such service is detailed. "Fast Recovery for EVPN Designated Forwarder Election", Patrice Brissette, Ali Sajassi, Luc Burdet, John Drake, Jorge Rabadan, 2023-07-10, The Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying Highest Random Weight (HRW) algorithm for Designated Forwarder election in order to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates Section 2.1 of [RFC8584] by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment and it is performed via a simple signaling between the recovered node and each of the other nodes in the multihoming group. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan, 2024-02-28, Etheret VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a family of solutions for Ethernet services over MPLS/IP network with many advanced features including multi-homing capabilities. These solutions introduce Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of Ethernet Virtual Circuits (EVCs e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs). Such an ES is referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. "Weighted Multi-Path Procedures for EVPN Multi-Homing", Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria, 2023-12-07, 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. "MVPN/EVPN Tunnel Aggregation with Common Labels", Zhaohui Zhang, Eric Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands, 2023-10-04, The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (abbreviated as VPNs). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. "EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, Eric Rosen, John Drake, Wen Lin, Jim Uttaro, Adam Simpson, 2023-10-09, 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 in [RFC4271], but only for IPVPN and EVPN families. "Extended Mobility Procedures for EVPN-IRB", Neeraj Malhotra, Ali Sajassi, Aparna Pattekar, Jorge Rabadan, Avinash Lingala, John Drake, 2023-10-16, The procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC7432. EVPN has since evolved to find wider applicability across various IRB use cases that include distributing both MAC and IP reachability via a common EVPN control plane. MAC Mobility procedures defined in RFC7432 are extensible to IRB use cases if a fixed 1:1 mapping between host IP and MAC is assumed across host moves. Generic mobility support for IP and MAC addresses that allows these bindings to change across moves IS REQUIRED to support a broader set of EVPN IRB use cases. EVPN all- active multi-homing further introduces scenarios that require additional consideration from mobility perspective. This document enumerates a set of design considerations applicable to mobility across these EVPN IRB use cases and updates sequence number assignment procedures defined in RFC7432 to address these IRB use cases. NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six authors which is above the required limit of five. Given significant and active contributions to the draft from all six authors over the course of six years, we would like to request IESG to allow publication with six authors. Specifically, the three Cisco authors are the original inventors of these procedures and contributed heavily to rev 0 draft, most of which is still intact. AT&T is also a key contributor towards defining the use cases that this document addresses as well as the proposed solution. Authors from Nokia and Juniper have further contributed to revisions and discussions steadily over last six years to enable respective implementations and a wider adoption. "PBB-EVPN ISID-based C-MAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Masahiro Miyake, Taku Matsuda, 2023-10-23, Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large Multi-Protocol Label Switching (MPLS) networks. That combination is what we refer to as PBB-EVPN. Single- Active Multi-homing and per-I-SID (per Service Instance Identifier) Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments (ES), PBB- EVPN defines a flush mechanism for Customer MACs (C-MAC-flush) that works for different Ethernet Segment Backbone MAC (B-MAC) address allocation models. This document complements those C-MAC-flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (the attachment circuit is associated to a zero Ethernet Segment Identifier) and a Service Instance Identifier based (I-SID- based) C-MAC-flush granularity is required. "Seamless Multicast Interoperability between EVPN and MVPN PEs", Ali Sajassi, Kesavan Thiruvenkatasamy, Samir Thoria, Ashutosh Gupta, Luay Jalil, 2023-10-23, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) and Enterprise networks as well as the next generation VPN services 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, 2023-12-30, 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. "BGP Based Multicast", Zhaohui Zhang, Lenny Giuliano, Keyur Patel, IJsbrand Wijnands, Mankamana Mishra, Arkadiy Gulko, 2023-12-02, This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multicast trees. "EVPN Port-Active Redundancy Mode", Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan, 2024-03-04, The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability while providing different modes of sharing/balancing of traffic. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document expands on existing redundancy mechanisms supported by EVPN and introduces a new Port- Active redundancy mode. "Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin, Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2023-12-23, In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. "EVPN Network Layer Fault Management", Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake, 2024-03-01, This document specifies proactive, in-band network layer OAM 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 (RFC 7432bis) network. The mechanisms specified in the draft use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol and other protocols as necessary. "BGP Usage for SD-WAN Overlay Networks", Linda Dunbar, Ali Sajassi, John Drake, Basil Najem, 2024-03-04, This document discusses the usage and applicability of BGP as the control plane for multiple scenarios of SD-WAN (Software Defined WAN) overlay networks. The document aims to demonstrate how the BGP-based control plane is used for large-scale SD-WAN overlay networks with minimum manual intervention. "EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan, Kiran Nagaraj, Wen Lin, Ali Sajassi, 2023-12-04, Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other tunnels, E.g., VXLAN tunnels. The existing specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document updates the EVPN Multihoming procedures in RFC8365 and RFC7432 so that an operator can decide the Split Horizon procedure for a given tunnel depending on their own requirements. "Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication", Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang, 2023-11-06, 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, 2024-02-13, 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)". "Multicast Source Redundancy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Wen Lin, 2024-01-22, Ethernet Virtual Private Network (EVPN) supports intra and inter- subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures. "Cumulative DMZ Link Bandwidth and load-balancing", MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, 2023-12-28, 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. "AC-Aware Bundling Service Interface in EVPN", Ali Sajassi, Mankamana Mishra, Samir Thoria, Jorge Rabadan, John Drake, 2023-11-15, An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. "SRv6 Argument Signaling for BGP Services", Ketan Talaulikar, Syed Raza, Jorge Rabadan, Wen Lin, 2023-10-24, RFC9252 defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 SID advertisements for BGP Service routes associated with SRv6 Endpoint Behaviors that support arguments. "IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI", Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2023-11-06, As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the five major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Ali Sajassi, Jorge Rabadan, S. Pasupula, Lukas Krattiger, John Drake, 2024-03-04, 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. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, 2024-02-05, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880. "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen, Peng Fan, 2024-01-31, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD packet loss. "Meticulous Keyed ISAAC for BFD Authentication", Alan DeKok, Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, 2024-02-04, This document describes a new BFD Authentication mechanism, Meticulous Keyed ISAAC. This mechanism 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 as an authenticated signal to maintain a session in the the "Up" state. This document updates RFC 5880. "BFD Encapsulated in Large Packets", Jeffrey Haas, Albert Fu, 2024-01-30, The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. "Unaffiliated BFD Echo", Weiqiang Cheng, Ruixue Wang, Xiao Min, Reshad Rahman, Raj Boddireddy, 2023-09-28, Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can quickly determine a communication failure between two forwarding engines. This document proposes a use of the BFD Echo where the local system supports BFD but the neighboring system does not support BFD. BFD Control packet and its processing procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. This document updates RFC 5880. Bit Indexed Explicit Replication (bier) --------------------------------------- "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, Zhaohui Zhang, 2023-06-13, Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information. "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Nagendra Nainar, Mach Chen, Santosh Pallagatti, 2024-02-11, This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow, 2023-11-05, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola, 2024-01-11, This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. "BIER Ping and Trace", Nagendra Nainar, Carlos Pignataro, Mach Chen, Greg Mirsky, 2024-01-27, 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 bit-string 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. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2023-09-18, 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, Zhaohui Zhang, Vengada Govindan, IJsbrand Wijnands, 2024-03-17, 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. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 2024-01-02, This document specifies protocols and procedures for forwarding broadcast, unknown unicast, and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). "BIER Penultimate Hop Popping", Zhaohui Zhang, 2024-02-06, Bit Index Explicit Replication (BIER) can be used as provider tunnel for Multicast Virtual Private Network (MVPN), Global Table Multicast or Ethernet Virtual Private Network (EVPN). It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER-incapable transit routers. However those methods assume the MVPN/EVPN Provider Edges (PEs) are BIER- capable. This document specifies a method to allow BIER-incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BIER Forwarding Router (BFR) that is connected directly or indirectly via a tunnel to a BIER-incapable PE remove the BIER header and send the payload to the PE. "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, 2024-01-23, This document defines a YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. "OSPFv3 Extensions for BIER", Peter Psenak, Nagendra Nainar, IJsbrand Wijnands, 2022-12-01, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER architecture uses MPLS or other encapsulation to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. The use of multiple encapsulation types is outside the scope of this document. "BIER Prefix Redistribute", Zheng Zhang, Bo Wu, Zhaohui Zhang, IJsbrand Wijnands, Yisong Liu, Hooman Bidgoli, 2024-03-04, This document defines a BIER proxy function to support a 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. "Tethering A BIER Router To A BIER incapable Router", Zhaohui Zhang, Nils Warnke, IJsbrand Wijnands, Daniel Awduche, 2024-02-16, This document specifies optional procedures to optimize the handling of Bit Index Explicit Replication (BIER) incapable routers, by attaching (tethering) a BIER router to a BIER incapable router. "M-LDP Signaling Through BIER Core", Hooman Bidgoli, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang, Eddie Leyton, 2023-10-22, 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, 2024-02-13, 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, 2023-10-08, 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, 2024-03-17, 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. "OSPF Extensions for BIER-TE", Huaimo Chen, Mike McBride, Zheng Zhang, Aijun Wang, Gyan Mishra, Yanhe Fan, 2024-02-01, This document describes OSPFv2 and OSPFv3 extensions for distributing the BitPositions configured on a Bit-Forwarding Router (BFR) with MPLS and non-MPLS encapsulation for "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) in a BIER-TE domain. "IS-IS Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2024-01-07, This document describes IS-IS extensions for distributing the BitPositions configured on a Bit-Forwarding Router (BFR) in a "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. "OSPFv3 Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2024-01-06, This document describes OSPFv3 extensions for distributing the BitPositions configured on a Bit-Forwarding Router (BFR) in a "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. "LSR Extensions for BIER non-MPLS Encapsulation", Senthil Dhanaraj, Gang Yan, IJsbrand Wijnands, Peter Psenak, Zhaohui Zhang, Jingrong Xie, 2024-02-07, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document updates RFC8296 and specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non- MPLS networks using BIER non-MPLS encapsulation. "Multicast/BIER As A Service", Zhaohui Zhang, Eric Rosen, Daniel Awduche, Greg Shepherd, Zheng Zhang, Gyan Mishra, 2024-02-06, This document describes a framework for providing multicast as a service via Bit Index Explicit Replication (BIER) [RFC7279], and specifies a few enhancements to [draft-ietf-bier-idr-extensions] [RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service. "BIER Fast ReRoute", Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra, 2024-02-01, BIER is a scalable multicast overlay that utilizes a routing underlay, e.g., IP, to build up its Bit Index Forwarding Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-FRR). It protects BIER traffic after detecting the failure of a link or node in the core of a BIER domain until affected BIFT entries are recomputed after reconvergence of the routing underlay. BIER-FRR is applied locally at the point of local repair (PLR) and does not introduce any per-flow state. The document specifies nomenclature for BIER-FRR and gives examples for its integration in BIER forwarding. Furthermore, it presents operation modes for BIER-FRR. Link and node protection may be chosen as protection level. Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based BIER-FRR are defined and compared. Benchmarking Methodology (bmwg) ------------------------------- "Multiple Loss Ratio Search", Maciek Konstantynowicz, Vratko Polak, 2024-03-04, This document proposes extensions to [RFC2544] 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 [RFC2544] is to address the challenges and requirements presented by the evaluation and testing of software-based networking systems' data planes. To give users more freedom, MLRsearch provides additional configuration options such as allowing multiple shorter 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. "A YANG Data Model for Network Tester Management", Vladimir Vassilev, 2024-03-04, This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. "Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers", Gabor Lencse, Keiichi Shima, 2024-01-23, RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. We discuss why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. We recommend a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). We show how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. We also define new performance metrics and measurement procedures for maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity measurements. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Tran Ngoc, Sridhar Rao, Jangwon Lee, Younghan Kim, 2024-02-19, Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resources allocation and network technologies are specified for containerized network functions. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. BPF/eBPF (bpf) -------------- "BPF Instruction Set Architecture (ISA)", Dave Thaler, 2024-03-04, This document specifies the BPF instruction set architecture (ISA). Calendaring Extensions (calext) ------------------------------- "Calendar subscription upgrades", Michael Douglass, 2024-02-15, 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. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Michael Douglass, 2023-11-06, This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. "JSContact: A JSON representation of contact data", Robert Stepanek, Mario Loffredo, 2024-03-04, This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. "Task Extensions to iCalendar", Adrian Apthorp, Michael Douglass, 2024-02-15, This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. "JSContact: Converting from and to vCard", Mario Loffredo, Robert Stepanek, 2024-03-04, This document defines how to convert contact information between the JSContact and vCard data formats. To achieve this, it updates RFC I- D.ietf-calext-jscontact (JSContact) by registering new JSContact properties. Similarly, it updates RFC 6350 (vCard) by registering new vCard properties and parameters. "vCard Format Extension for JSContact", Robert Stepanek, Mario Loffredo, 2024-03-04, This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates RFC 6350 (vCard). Computing-Aware Traffic Steering (cats) --------------------------------------- "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Kehan Yao, Dirk Trossen, Mohamed Boucadair, Luis Contreras, Hang Shi, Yizhou Li, Shuai Zhang, Qing An, 2024-01-01, Distributed computing is a tool that service providers can use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities aids support of services such as computationally intensive and delay sensitive services. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response times. 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 best meet the customer's expectations and deliver the requested service. "A Framework for Computing-Aware Traffic Steering (CATS)", Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake, 2024-03-17, This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Packed CBOR", Carsten Bormann, Mikolai Guetschow, 2024-03-02, 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 receiver needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a simple transformation of a CBOR data item into another 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 receiver. // The present version (-12) updates the IANA "Values for Tag // Numbers" table, sorting it and cleaning up the "Data Item" column. "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", Carsten Bormann, Ben Gamari, Henk Birkholz, 2023-10-30, 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 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined. // (This cref will be removed by the RFC editor:) The present // revision (–12) addresses the IESG reviews. "CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals, ABNF, and Media Type", Carsten Bormann, 2024-02-01, The Concise Binary Object Representation, CBOR (STD 94, RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. This document specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions for text representations of epoch-based date/times and of IP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. To facilitate tool interoperation, this document specifies a formal ABNF definition for extended diagnostic notation (EDN) that accommodates application- oriented literals. "More Control Operators for CDDL", Carsten Bormann, 2024-02-26, The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (Bytes, Integers, JSON, Printf-style formatting), operations on text, and deterministic encoding. "Updates to the CDDL grammar of RFC 8610", Carsten Bormann, 2024-03-02, The Concise Data Definition Language (CDDL), as defined in RFC 8610 and RFC 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in CBOR or JSON. The present document updates RFC 8610 by addressing errata and making other small fixes for the ABNF grammar defined for CDDL there. "CDDL Module Structure", Carsten Bormann, Brendan Moran, 2024-03-04, At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and 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, 2024-03-03, 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) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. This document also introduces the concept of Application Profiles, which are layered on top of the CBOR CDE Profile and can address more application specific requirements. Application Profiles are defined in separate documents. 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, 2023-07-10, This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. This model enables clients, which interact with a transport domain controller, for OTN topology-related operations such as obtaining the relevant topology resource information. "OTN Tunnel YANG Model", Haomian Zheng, Italo Busi, Sergio Belotti, Victor Lopez, Yunbin Xu, 2023-11-24, 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, 2024-01-29, 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-02-07, 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 for Microwave Topology", Scott Mansfield, Jonas Ahlberg, Min Ye, Xi Li, Daniela Spreafico, 2024-02-28, This document defines a YANG data model to describe microwave/ millimeter radio links in a network topology. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application", Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller, 2024-01-23, This memo defines extensions to LMP RFC4209 for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1 and its extensions. "A YANG model to manage the optical interface parameters for an external transponder in a WDM network", Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer, 2023-10-23, 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. Is to be noted that the Transceivers can be located on the Transponders (optical layer) or on the Router (in general packet layer) in form of Pluggable modules. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link. The use of this model does not guarantee interworking of transceivers over a DWDM. 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, 2024-03-04, 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, 2024-01-29, 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, 2023-10-09, 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, 2024-01-24, 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. "A YANG Data Model for Layer 0 Types", Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo, 2024-03-04, This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) 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. "YANG Data Model for FlexE Management", Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu, 2024-02-27, 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, 2023-10-19, 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, 2024-03-01, 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 Bandwidth Availability Topology", Jonas Ahlberg, Scott Mansfield, Min Ye, Italo Busi, Xi Li, Daniela Spreafico, 2023-10-18, This document defines a YANG data model to describe bandwidth availability for a link in a network topology. "A YANG Data Model for Interface Reference Topology", Jonas Ahlberg, Scott Mansfield, Min Ye, Italo Busi, Xi Li, Daniela Spreafico, 2023-10-18, This document defines a YANG data model to provide a reference from a termination point in a topology model to interface management information. "A YANG Data Model for WDM Tunnels", Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero, 2024-03-01, 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). Congestion Control Working Group (ccwg) --------------------------------------- "Specifying New Congestion Control Algorithms", Martin Duke, Gorry Fairhurst, 2024-02-02, Introducing new or modified congestion controller algorithms in the global Internet have possible ramifications to both the traffic using the new method and to traffic using a standardized congestion control algorithm. Therefore, the IETF must proceed with caution when evaluating proposals for alternate congestion control. The goal of this document is to provide guidance for considering standardization of an alternate congestion control algorithm at the IETF. It replaces RFC5033 to reflect changes in the congestion control landscape. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition", Nir Sopher, Ori Finkelman, Sanjay Mishra, Jay Robertson, 2024-03-04, 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 pre-position metadata or content as well as request that it invalidate or purge metadata or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. "CDNI Metadata for Delegated Credentials", Frederic Fieau, Stephan Emile, Guillaume Bichot, Christoph Neumann, 2024-02-19, The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document defines metadata in the CDNI Control and Metadata interface to setup HTTPS delegation using delegated credentials from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). "CDNI Capacity Capability Advertisement Extensions", Andrew Ryan, Ben Rosenblum, Nir Sopher, 2024-03-04, 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 supplements to the CDNI Capability Objects defined in RFC 8008 the defined capability objects structure and interface for advertisements and management of a downstream CDN capacity. "CDNI Cache Control Metadata", Will Power, Glenn Goldstein, 2024-03-04, This specification adds to the basic cache control metadata defined in RFC8006, providing content providers and upstream CDNs (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the origin, bypassing caching altogether, or altering cache keys with dynamically generated values. "CDNI Edge Control Metadata", Alfonso Siloniz, Glenn Goldstein, 2023-10-18, 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, 2024-03-01, 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. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice, Jerome Martinez, 2024-01-17, This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. "Matroska Media Container Format Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2023-10-22, This document defines the Matroska audiovisual data container structure, including definitions of its structural elements, as well as its terminology, vocabulary, and application. This document updates [RFC8794] to permit the use of a previously reserved EBML Element ID. "Matroska Media Container Codec Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2024-01-27, 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, 2023-10-22, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. "Free Lossless Audio Codec", Martijn van Beurden, Andrew Weaver, 2024-01-14, This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals without losing information in doing so (i.e., lossless). FLAC is free in the sense that its specification is open and its reference implementation is open-source. Compared to other lossless (audio) coding formats, FLAC is a format with low complexity and can be coded to and from with little computing resources. Decoding of FLAC has seen many independent implementations on many different platforms, and both encoding and decoding can be implemented without needing floating- point arithmetic. "Matroska Media Container Control Track Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2024-01-27, This document defines the Control Track usage found in the Matroska container. "Matroska Media Container Chapter Codecs Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2024-01-27, This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. Crypto Forum (cfrg) ------------------- "KangarooTwelve and TurboSHAKE", Benoit Viguier, David Wong, Gilles Van Assche, Quynh Dang, Joan Daemen, 2024-02-06, 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 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, 2023-09-18, 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, 2023-09-25, 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. "The OPAQUE Asymmetric PAKE Protocol", Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood, 2023-12-18, This document describes the OPAQUE protocol, a secure 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. "Two-Round Threshold Schnorr Signatures with FROST", Deirdre Connolly, Chelsea Komlo, Ian Goldberg, Christopher Wood, 2023-09-18, This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime- order groups and hash functions. One such ciphersuite can be used to produce signatures that can be verified with an Edwards-Curve Digital Signature Algorithm (EdDSA, as defined in RFC8032) compliant verifier. However, unlike EdDSA, the signatures produced by FROST are not deterministic. 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, 2023-11-20, 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 measurement that would result in an invalid aggregate result. "Key Blinding for Signature Schemes", Frank Denis, Edward Eaton, Tancrede Lepoint, Christopher Wood, 2024-01-22, 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, 2024-01-20, 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, 2024-03-16, 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, 2023-12-21, 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 it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages. "Deterministic Nonce-less Hybrid Public Key Encryption", Dan Harkins, 2024-02-05, 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. "Properties of AEAD Algorithms", Andrey Bozhko, 2024-02-29, Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. "Implementation Guidance for the PKCS #1 RSA Cryptography Specification", Hubert Kario, 2024-03-04, 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. 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-02-23, 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 further identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. 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, 2023-10-20, 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. "YANG Schema Item iDentifier (YANG SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, Carsten Bormann, Michael Richardson, 2023-12-22, YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (–24) is intended to address the remaining // IESG comments. "CoAP Management Interface (CORECONF)", Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann, 2024-03-04, 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, 2024-03-04, 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. "The Constrained RESTful Application Language (CoRAL)", Christian Amsuess, Thomas Fossati, 2024-03-04, The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. "Constrained Resource Identifiers", Carsten Bormann, Henk Birkholz, 2024-01-09, 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) instead of a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –14 of this draft picks up comments from the // shepherd review and adds sections on CoAP integration and on cri // application-oriented literals for the Extended Diagnostic // Notation. This revision still contains open issues and is // intended to serve as a snapshot while the processing of the // shepherd review is being completed. "Group Communication for the Constrained Application Protocol (CoAP)", Esko Dijk, Chonggang Wang, Marco Tiloca, 2023-10-23, 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. "Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)", Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander, 2023-11-29, The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. "Observe Notifications as CoAP Multicast Responses", Marco Tiloca, Rikard Hoeglund, Christian Amsuess, Francesca Palombini, 2024-03-04, 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. "Key Update for OSCORE (KUDOS)", Rikard Hoeglund, Marco Tiloca, 2024-03-04, 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. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. "Attacks on the Constrained Application Protocol (CoAP)", John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess, 2024-02-21, 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, 2024-03-18, 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] 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, 2024-03-04, This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are 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). "CoRE Target Attributes Registry", Carsten Bormann, 2023-10-11, The Constrained RESTful Environments (CoRE) specifications apply Web technologies to constrained environments. One important such technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in CoAP's Resource Discovery Protocol (Section 7.2 of RFC7252) and the Resource Directory (RD, RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the RD Parameters IANA Registry created by RFC 9176 to coordinate with this registry. "Key Usage Limits for OSCORE", Rikard Hoeglund, Marco Tiloca, 2024-01-10, 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, Massimo Nilo, Fabrizio Milan, Fabio Bulgarella, 2023-10-19, 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, 2024-03-04, 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, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach 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, 2024-03-04, 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 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, 2024-03-05, 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. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Encoded X.509 Certificates (C509 Certificates)", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2024-03-04, 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 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, 2023-10-22, 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 one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. "CBOR Web Token (CWT) Claims in COSE Headers", Tobias Looker, Michael Jones, 2023-11-29, This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. "Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE", Tobias Looker, Michael Jones, 2024-03-17, 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, 2024-01-12, This document describes JOSE and COSE serializations for ML-DSA, which was derived from Dilithium, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-204]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/post-quantum-cryptography) standardization process. "SLH-DSA for JOSE and COSE", Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans, 2024-01-12, This document describes JOSE and COSE serializations for SLH-DSA, which was derived from SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-205]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/post-quantum-cryptography) standardization process. "CBOR Object Signing and Encryption (COSE) Key Thumbprint", Kohei Isobe, Hannes Tschofenig, Orie Steele, 2023-10-23, This specification defines a method for computing a hash value over a COSE Key. It defines which fields in a COSE Key structure are used in the hash computation, the method of creating a canonical form of the fields, and how to hash the byte sequence. The resulting hash value can be used for identifying or selecting a key that is the subject of the thumbprint. "COSE Receipts", Orie Steele, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, 2024-03-02, 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 "typ" (type) Header Parameter", Michael Jones, Orie Steele, 2024-03-04, This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) typ (type) header parameter to CBOR Object Signing and Encryption (COSE) so that the benefits of explicit typing, as defined in the JSON Web Token Best Current Practices BCP, can be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. "COSE Header parameter for RFC 3161 Time-Stamp Tokens", Henk Birkholz, Thomas Fossati, Maik Riechert, 2024-02-24, RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSE_Sign and COSE_Sign1) with existing RFC 3161-based timestamping infrastructure. DANE Authentication for Network Clients Everywhere (dance) ---------------------------------------------------------- "TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor Dukhovni, 2024-01-13, The DANE TLSA protocol [RFC6698] [RFC7671] 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, 2024-01-08, 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, 2024-01-30, 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. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking (DetNet) YANG Model", Xuesong Geng, Yeoncheol Ryoo, Don Fedyk, Reshad Rahman, Zhenqiang Li, 2024-02-23, This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data of DetNet Flows. The model allows for provisioning of end-to-end DetNet service on devices along the path without dependency on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). "Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane", Greg Mirsky, Mach Chen, David Black, 2024-02-14, This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. "Reliable and Available Wireless Technologies", Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas, 2023-07-10, This document presents a series of recent technologies that are capable of time synchronization and scheduling of transmission, making them suitable to carry time-sensitive flows with high reliability and availability. "Deterministic Networking (DetNet) Controller Plane Framework", Andrew Malis, Xuesong Geng, Mach Chen, Fengwei Qin, Balazs Varga, Carlos Bernardos, 2023-09-26, 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, 2024-03-04, Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity across any combination of wired and wireless network segments. The RAW Architecture extends the DetNet Architecture and other standard IETF concepts and mechanisms to adapt to the specific challenges of the wireless medium, in particular intermittently lossy connectivity. This document defines a network control loop that optimizes the use of constrained spectrum and energy while maintaining the expected connectivity properties, typically reliability and latency. The loop involves DetNet Operational Plane functions, with a new recovery Function and a new Point of Local Repair operation, that dynamically selects the DetNet path(s) for the future packets to route around local degradations and failures. "Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP", Balazs Varga, Janos Farkas, Andrew Malis, 2024-02-22, This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. "Deterministic Networking (DetNet): Packet Ordering Function", Balazs Varga, Janos Farkas, Stephan Kehrer, Tobias Heer, 2024-01-15, Replication and Elimination functions of DetNet Architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. The Packet Ordering Function (POF) algorithm described herein enables to restore the correct packet order when replication and elimination functions are used in DetNet networks. POF only provides ordering within the latency bound of a DetNet flow, and does not provide any additional reliability. "Requirements for Scaling Deterministic Networks", Peng Liu, Yizhou Li, Toerless Eckert, Quan Xiong, Jeong-dong Ryoo, zhushiyin, Xuesong Geng, 2023-11-20, Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, 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. "Requirements for Reliable Wireless Industrial Services", Rute Sofia, Paulo Mendes, Carlos Bernardos, Eve Schooler, 2024-01-19, This document provides an overview of the communication requirements for handling reliable wireless services in the context of industrial environments. The aim of the draft is to raise awareness of the communication requirements of current and future wireless industrial services; how they can coexist with wired infrastructures; the key drivers for reliable wireless integration; the relevant communication requirements to be considered; the current and future challenges arising from the use of wireless services; and the potential benefits of wireless communication. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters, 2024-02-26, This document describes 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 replaces 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). "Registering Self-generated IPv6 Addresses using DHCPv6", Warren Kumari, Suresh Krishnan, Rajiv Asati, Lorenzo Colitti, Jen Linkova, Sheng Jiang, 2024-01-26, This document defines a method to inform a DHCPv6 server that a device has a self-generated or statically configured address. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Todd Herr, John Levine, 2024-02-28, This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, 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) Failure Reporting", Steven Jones, Alessandro Vesely, 2024-03-17, 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. "DMARC Aggregate Reporting", Alex Brotman, 2024-02-28, DMARC allows for domain holders 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 to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes [RFC7489]. Distributed Mobility Management (dmm) ------------------------------------- "Mobility aware Transport Network Slicing for 5G", Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley, 2024-02-29, Network slicing in 5G supports 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 services, user's data plane packets over the radio access network (RAN) and mobile core network (5GC) use IP transport in many segments of the end-to-end 5G slice. When end-to- end slices in a 5G system use IP network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation and other criteria requested by the 5G slice. This document describes mapping of 5G slices to IP or Layer 2 transport network slices when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping proposed here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. "Architecture Discussion on SRv6 Mobile User plane", Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali, Luay Jalil, 2024-02-15, This document discusses the solution approach and its architectural benefits of translating mobile session information into routing information, applying segment routing capabilities, and operating in the IP routing paradigm. Domain Name System Operations (dnsop) ------------------------------------- "IP Fragmentation Avoidance in DNS over UDP", Kazunori Fujiwara, Paul Vixie, 2024-02-29, The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document specifies techniques to avoid IP fragmentation in DNS. "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Willem Toorop, 2024-03-17, This document recommends improved DNS [RFC1034] [RFC1035] resolver behavior with respect to the processing of Name Server (NS) resource record sets (RRset) 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 child delegation by re-querying the parent zone at the expiration of the TTL of the parent side NS RRset. "DNS Terminology", Paul Hoffman, Kazunori Fujiwara, 2023-09-25, The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. "DNS Error Reporting", Roy Arends, Matt Larson, 2024-03-04, DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in [RFC8914]. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME, thus the very act of sending the query is to report the error. "The DNS Zone Version (ZONEVERSION) Option", Hugo Salgado, Mauricio Ereche, Duane Wessels, 2024-01-15, The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The Serial field from the Start Of Authority (SOA) resource record is a good example of a zone's version, and the only one defined by this specification. Additional version types may be defined by future specifications. Including zone version data in a response simplifies and improves the quality of debugging and and diagnostics since the version and the data are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the NSID option. "Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator", Peter Thomassen, Nils Wisiol, 2024-01-19, This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] "DNSSEC automation", Ulrich Wisser, Shumon Huque, Johan Stenstam, 2023-10-22, This document describes an algorithm and protocol to automate the setup, operations, and decomissioning of Multi-Signer DNSSEC [RFC8901] configurations. It employs Model 2 of the Multi-Signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), Managing DS Records from the Parent via CDS/ CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477] to accomplish this. "Domain Control Validation using DNS", Shivan Sahib, Shumon Huque, Paul Wouters, Erik Nygren, 2024-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 requester's domain. There is wide variation in the details of these methods today. This document proposes 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, 2023-11-29, 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, 2024-01-31, 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, 2024-03-04, 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 minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. 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/shuque/id-dnssec-compact-lies. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2024-02-14, This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. See Section 1.1 for the list of changes from RFC 8109. "Consistency for CDS/CDNSKEY and CSYNC is Mandatory", Peter Thomassen, 2023-10-02, Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. RFC 7344 automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. 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) typically discover these records by querying them from the child, and then use them to update the parent-side RRsets of the delegation accordingly. 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, 2024-03-04, This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new NOTIFY record type. 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. "In the DNS, QDCOUNT is (usually) One", Ray Bellis, Joe Abley, 2024-03-04, This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. "DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob Schlyter, Guillaume Bailey, Paul Hoffman, 2024-03-04, The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "Service Registration Protocol for DNS-Based Service Discovery", Ted Lemon, Stuart Cheshire, 2024-03-04, The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. "An EDNS(0) option to negotiate Leases on DNS Updates", Stuart Cheshire, Ted Lemon, 2023-07-07, This document describes an EDNS(0) option that can be used by DNS Update requestors and DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale resource records that have been added by DNS Updates "Advertising Proxy for DNS-SD Service Registration Protocol", Stuart Cheshire, Ted Lemon, 2024-03-04, An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNS-SD Service Registration Protocol (SRP), using multicast DNS. This allows legacy clients to discover services registered with SRP using multicast DNS. "Automatic Replication of DNS-SD Service Registration Protocol Zones", Ted Lemon, Abtin Keshavarzian, Jonathan Hui, 2024-03-04, This document describes a protocol that can be used for ad-hoc replication of a DNS zone by multiple servers where a single primary DNS authoritative server is not available and the use of stable storage is not desirable. "DNS Multiple QTYPEs", Ray Bellis, 2023-12-04, 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. Drone Remote ID Protocol (drip) ------------------------------- "DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2024-02-21, The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. "DRIP Entity Tag (DET) Identity Management Architecture", Adam Wiethuechter, Jim Reid, 2023-12-04, This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. "The DRIP DET public Key Infrastructure", Robert Moskowitz, Stuart Card, 2023-12-19, 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. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. 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) ------------------------------------------ "DTN Management Architecture", Edward Birrane, Sarah Heiner, Emery Annis, 2024-03-18, The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices. This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over uni-directional links and other places where BP is the preferred transport. "Update to the ipn URI scheme", Rick Taylor, Edward Birrane, 2024-02-21, This document updates both the specification of the ipn URI scheme previously defined in RFC 7116 and the rules for encoding of these URIs when used as an Endpoint Identifier (EID) in Bundle Protocol Version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the ipn URI scheme, define encodings of ipn scheme URIs, and establish the registries necessary to manage this scheme. "DTN Bundle Protocol Security (BPSec) COSE Context", Brian Sipos, 2024-01-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, 2024-02-22, 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, 2024-02-22, This document defines a data 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 type definitions, data structures, and a template for publishing standardized representations of model elements. 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. Revision of core Email specifications (emailcore) ------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 2024-02-26, 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, Ekow Sam, 2023-12-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. "Internet Message Format", Pete Resnick, 2024-01-27, 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) ----------------------- "Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)", Jari Arkko, Karl Norrman, John Mattsson, 2024-02-19, This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead. "Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)", Owen Friel, Dan Harkins, 2024-02-17, 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, 2024-02-26, 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. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "Sieve Email Filtering: Extension for Processing Calendar Attachments", Kenneth Murchison, Ricardo Signes, Matthew Horsfall, 2024-03-16, This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME). "IMAP MESSAGELIMIT Extension", Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Luis Alves, 2024-02-01, The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE/APPEND/EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by corresponding IMAP server and avoid issuing commands that would exceed such limit. "The JMAPACCESS Extension for IMAP", Arnt Gulbrandsen, Bron Gondwana, 2024-03-01, This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via JMAP, and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. "IMAP Extension for only using and returning UIDs", Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Ashutosh Singh, Luis Alves, 2024-03-18, The UIDONLY extension to the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses, and can't be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs. This document defines an experimental IMAP extension. "IMAP4 Response Code for Command Progress Notifications.", Marco Bettini, 2024-02-14, This document defines a new IMAP untagged response code, "INPROGRESS", that provides structured numeric progress status indication for long-running commands. "IMAP4 Extension for Returning Mailbox METADATA in Extended LIST", Kenneth Murchison, Bron Gondwana, 2024-03-18, This document defines an extension to the to IMAP LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. "Snoozing Email with IMAP, JMAP, and Sieve", Kenneth Murchison, Ricardo Signes, Neil Jenkins, 2023-10-30, This document describes the "snooze" extensions to IMAP, JMAP for Mail, and the Sieve Email Filtering Language. The "snooze" extensions give these protocols the ability to postpone the appearance of an email message in a target mailbox until a later point in time. Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- "Grant Negotiation and Authorization Protocol", Justin Richer, Fabien Imbault, 2024-03-11, GNAP defines a mechanism for delegating authorization to a piece of software, and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. "Grant Negotiation and Authorization Protocol Resource Server Connections", Justin Richer, Fabien Imbault, 2024-02-19, GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This extension defines methods for resource servers (RS) to connect with authorization servers (AS) in an interoperable fashion. Global Routing Operations (grow) -------------------------------- "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Alexander Azimov, 2024-01-08, 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 Peer Up Message Namespace", John Scudder, Paolo Lucente, 2024-02-06, RFC 7854, BMP, uses different message types for different purposes. Most of these are Type, Length, Value (TLV) structured. One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Subsequent experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol. This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFC 8671 and RFC 9069 by moving the defined codepoints in the newly introduced registry. The changes in this document are formal only, compliant implementations of RFC 7854, RFC 8671 and RFC 9069 also comply with this specification. "BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages", Paolo Lucente, Yunan Gu, 2024-03-18, Most of the message types defined by the BGP Monitoring Protocol (BMP) make provision for data in 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 allows for a homogeneous and extensible surface that would be useful for the most different use-cases that need to convey additional data to a BMP station. While it is not intended for this document to cover any specific utilization scenario, it defines a simple way 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, 2024-02-07, AS Path Prepending provides a tool to manipulate the BGP AS_PATH attribute through prepending multiple entries of an ASN. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. 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, 2024-03-18, 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, 2023-11-26, 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, 2023-12-29, This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). "A well-known BGP community to denote prefixes used for Anycast", Maximilian Wilhelm, Fredy Kuenzler, 2023-11-26, In theory routing decisions on the Internet and by extension within ISP networks should always use hot-potato routing to reach any given destination. In reality operators sometimes choose to not use the hot-potato paths to forward traffic due to a variety of reasons, mostly motivated by traffic engineering considerations. For prefixes carrying anycast traffic in virtually all situations it is advisable to stick to the hot-potato principle. As operators mostly don't know which prefixes are carrying unicast or anycast traffic, they can't differentiate between them in their routing policies. To allow operators to take well informed decisions on which prefixes are carrying anycast traffic this document proposes a well-known BGP community to denote this property. "BMP Extension for Path Status TLV", Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf, 2024-03-18, The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a path after being processed by the BGP process. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-ietf-grow-bmp-tlv-ebit [I-D.ietf-grow-bmp-tlv-ebit]. "Logging of routing events in BGP Monitoring Protocol (BMP)", Paolo Lucente, Camilo Cardona, 2024-03-18, 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. "YANG Module for BGP Communities", Martin Pels, 2024-02-22, 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 standardised format. "Definition For New BMP Statistics Type", Mukul Srivastava, 2024-01-22, RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router. This document updates RFC 7854 by adding new statistics type. "Updated BGP Operations and Security", Tobias Fiebig, 2024-01-26, The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability measures that can and should be deployed 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, reiterating the best practices for BGP security from that document and adding new practices and recommendations that emerged since its publication. This document provides a comprehensive list of Internet specific BGP security and reliability related best practices as of the time of publication. It specifically does not cover other uses of BGP, e.g., in a datacenter context. While the recommendations in this document are, in general, best practices, operators still need to carefully weigh individual measures vs. their local network requirements before implementing them. Also, as with BCP194, best practices outlined in this document may have changed since its publication. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Guidelines for Human Rights Protocol and Architecture Considerations", Gurshabad Grover, Niels ten Oever, 2024-02-12, This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations [RFC6973]. This is an updated version of the guidelines for human rights considerations in [RFC8280]. This document is not an Internet Standards Track specification; it is published for informational purposes. This informational document has consensus for publication from the Internet Research Task Force (IRTF) Human Right Protocol Considerations Research (HRPC) Group. It has been reviewed, tried, and tested by both by the research group as well as by researchers and practitioners from outside the research group. The research group acknowledges that the understanding of the impact of Internet protocols and architecture on society is a developing practice and is a body of research that is still in development. "Intimate Partner Violence Digital Considerations", Sofia Celi, Juliana Guerra, Mallory Knodel, 2023-10-18, This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These kinds of technical compromise exist in addition to on-path attacks, both active and passive [RFC7624]. In this document we describe the tactics the IPV attacker uses and what kind of counter-measures can be designed in IETF protocols. Building Blocks for HTTP APIs (httpapi) --------------------------------------- "The Deprecation HTTP Header Field", Sanjay Dalal, Erik Wilde, 2023-12-11, The Deprecation HTTP response header field is used to signal to consumers of a URI-identified resource that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional information about planned or existing deprecation, and possibly ways in which clients can best manage deprecation. "The Idempotency-Key HTTP Header Field", Jayadeba Jena, Sanjay Dalal, 2023-11-16, The HTTP Idempotency-Key request header field can be used to carry idempotency key in order to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. "REST API Media Types", Roberto Polli, 2024-01-07, This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. "The Link-Template HTTP Header Field", Mark Nottingham, 2024-01-30, This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. "Link relationship types for authentication", Evert Pot, 2024-03-03, This specification defines a set of relationships that may be used to indicate where a user may authenticate, log out, register a new account or find out who is currently authenticated. "HTTP Link Hints", Mark Nottingham, 2024-02-25, 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. "api-catalog: a well-known URI and link relation to help discovery of APIs", Kevin Smith, 2024-03-04, This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of the APIs published by a given organisation or individual. HTTP (httpbis) -------------- "Cookies: HTTP State Management Mechanism", Steven Bingler, Mike West, John Wilander, 2023-11-15, 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. "Resumable Uploads for HTTP", Marius Kleidl, Guoye Zhang, Lucas Pardue, 2024-03-04, HTTP clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. Prior to interruption, part of a representation may have been exchanged. To complete the data transfer of the entire representation, it is often desirable to issue subsequent requests that transfer only the remainder of the representation. 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. "Structured Field Values for HTTP", Mark Nottingham, Poul-Henning Kamp, 2024-01-23, This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document obsoletes RFC 8941. "The Signature HTTP Authentication Scheme", David Schinazi, David Oliver, Jonathan Hoyland, 2024-01-23, Existing HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document proposes a new non-probeable cryptographic authentication scheme. "Template-Driven HTTP CONNECT Proxying for TCP", Benjamin Schwartz, 2023-12-07, 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. "Secondary Certificate Authentication of HTTP Servers", Eric Gorbaty, Mike Bishop, 2023-10-12, This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. "Compression Dictionary Transport", Patrick Meenan, Yoav Weiss, 2024-02-27, This specification defines a mechanism for using designated HTTP responses as an external dictionary for future HTTP responses for compression schemes that support using external dictionaries (e.g., Brotli (RFC 7932) and Zstandard (RFC 8878)). "HTTP Cache Groups", Mark Nottingham, 2023-12-18, 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 opaque strings. 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, 2019-09-16, 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) --------------------------------- "Partitioning as an Architecture for Privacy", Mirja Kuehlewind, Tommy Pauly, Christopher Wood, 2024-01-11, This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. "IAB Barriers to Internet Access of Services (BIAS) Workshop Report", Mirja Kuehlewind, Dhruv Dhody, Mallory Knodel, 2024-02-23, The “Barriers for Internet Access of Services (Bias)” workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role of community networks in Internet Access of Services; reports and comments on the observed digital divide; and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussion and serves as a reference for reports on the current barriers to Internet Access. 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, 2024-01-29, This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. Information-Centric Networking (icnrg) -------------------------------------- "File-Like ICN Collections (FLIC)", Christian Tschudin, Christopher Wood, Marc Mosko, David Oran, 2023-10-22, This document describes a simple "index table" data structure and its associated Information Centric Networking (ICN) data objects for organizing a set of primitive ICN data objects into a large, File- Like ICN Collection (FLIC). At the core of this collection is a _manifest_ which acts as the collection's root node. The manifest contains an index table with pointers, each pointer being a hash value pointing to either a final data block or another index table node. Inter-Domain Routing (idr) -------------------------- "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Jie Dong, Mach Chen, Robert Raszuk, 2024-03-04, The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang, 2023-10-16, 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 Dissemination of Flow Specification Rules for Tunneled Traffic", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2023-12-26, 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. "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari, Kotikalapudi Sriram, Lilia Hannachi, Jeffrey Haas, 2024-01-10, BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it proscribes the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 and RFC 5065, and obsoletes RFC 6472. "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu, 2024-01-03, 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. It is referred to as BGP BFD "strict-mode". BGP BFD strict-mode will be supported when both the local speaker and its remote peer are BFD strict-mode capable. "SR Policy Extensions for Path Segment and Bidirectional Path", Cheng Li, Zhenbin Li, Yuanyang Yin, Weiqiang Cheng, Ketan Talaulikar, 2024-02-19, A Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. For each SR path, it may also have its own path attributes, and Path Segment is one of them. A Path Segment is defined to identify an SR path, which can be used for performance measurement, path correlation, and end-2-end path protection. Path Segment can be also used to correlate two unidirectional SR paths into a bidirectional SR path which is required in some scenarios, for example, mobile backhaul transport network. This document defines extensions to BGP to distribute SR policies carrying Path Segment and bidirectional path information. "BGP Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang Ou, Yujia Luo, Gyan Mishra, Huaimo Chen, Haibo Wang, 2023-12-31, It is hard to adjust traffic in a traditional IP network from time to time through manual configurations. It is desirable to have a mechanism for setting up routing policies, which adjusts traffic automatically. This document describes BGP Extensions for Routing Policy Distribution (BGP RPD) to support this with a controller. "SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS", Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar, 2024-02-19, 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, 2023-10-19, 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 SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. 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, 2024-01-27, 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. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. 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. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The 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, 2023-10-20, 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, Kausik Majumdar, Susan Hares, Robert Raszuk, Venkit Kasiviswanathan, 2023-10-14, The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. 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 turns 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, Lei Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, 2023-10-08, This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. "BGP Flow Specification Version 2", Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke, 2023-10-23, 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. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. 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. "BGP-LS Extensions for IS-IS Flood Reflection", Jordan Head, Tony Przygienda, 2024-02-09, IS-IS Flood Reflection is a mechanism that allows flat, single-area IS-IS topologies to scale beyond their traditional limitations. This document defines new BGP-LS (BGP Link-State) TLVs in order to carry IS-IS Flood Reflection information. "BGP for BIER-TE Path", Huaimo Chen, Mike McBride, Ran Chen, Gyan Mishra, Aijun Wang, Yisong Liu, Yanhe Fan, Boris Khasanov, Lei Liu, Xufeng Liu, 2023-12-31, This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path. "Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP", Giuseppe Fioccola, Ran Pang, Subin Wang, Bruno Decraene, Shunwan Zhuang, Haibo Wang, 2024-01-11, 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 BGP Router Capability Code to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability 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, Co-authors, 2024-02-02, This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. This solution is called BGP Color-Aware Routing (BGP CAR). "BGP Classful Transport Planes", Kaliraj Vairavakkalai, Natrajan Venkataraman, 2024-03-17, 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 procedures and follows RFC 8277 NLRI encoding is defined to advertise underlay routes with its identified 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, 2023-06-16, 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 Capabilities Attribute", Bruno Decraene, John Scudder, Wim Henderickx, Kireeti Kompella, MOHANTY Satya, Jim Uttaro, Bin Wen, 2024-03-01, 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 capabilities, or other properties, to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such capability information, the "Next Hop Dependent Capabilities Attribute," or NHC. Unlike the capabilities defined by RFC 5492, those 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 capability 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, Haibo Wang, Gyan Mishra, Zongpeng Du, 2024-02-21, This draft describes a new Metadata Path Attribute and some Sub-TLVs for egress routers to advertise the 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). "BGP Extended Community for Identifying the Target Nodes", Jie Dong, Shunwan Zhuang, Gunter Van de Velde, Jeff Tantsura, 2024-03-04, BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose. "VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong, 2024-03-19, This draft defines a new Outbound Route Filter (ORF) type, called the VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session (e.g., routers in a single-domain connect via Route Reflector). "BGP Flowspec for IETF Network Slice Traffic Steering", Jie Dong, Ran Chen, Subin Wang, Jiang Wenying, 2024-03-04, 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 preformed 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). "Extended Communities Derived from Route Targets", Zhaohui Zhang, Jeffrey Haas, Keyur Patel, 2024-01-17, This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. "Advertisement of Segment Routing Policies using BGP Link-State", Stefano Previdi, Ketan Talaulikar, Jie Dong, Hannes Gredler, Jeff Tantsura, 2023-11-05, 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. "Advertisement of Traffic Engineering Paths using BGP Link-State", Stefano Previdi, Ketan Talaulikar, Jie Dong, Hannes Gredler, Jeff Tantsura, 2023-09-29, This document describes a mechanism to collect the Traffic Engineering Path 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. "Border Gateway Protocol 4 (BGP-4) Send Hold Timer", Job Snijders, Ben Cartwright-Cox, Yingzhen Qu, 2024-02-29, This document defines the SendHoldTimer and SendHoldTime session attributes for the Border Gateway Protocol (BGP) Finite State Machine (FSM). Implementation of the SendHoldTimer helps overcome situations where a BGP session is not terminated after the local system detects that the remote system is not processing BGP messages. This document specifies that the local system should close the BGP connection and not solely rely on the remote system for session closure when the SendHoldTimer expires. This document updates RFC4271. "BGP Extension for SR-MPLS Entropy Label Position", Yao Liu, Shaofu Peng, 2024-02-05, 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, 2024-03-04, This document specifies the signaling of additional Segment Routing Segment Types for BGP SR Policy SAFI. "BGP CT - Adaptation to SRv6 dataplane", Kaliraj Vairavakkalai, Natrajan Venkataraman, 2024-03-04, This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document. "BGP SR Policy Extensions for Network Resource Partition", Jie Dong, Zhibo Hu, Ran Pang, 2023-12-17, 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 XXXX 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, 2023-12-17, 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 Colored Prefix Routing (CPR) for SRv6 based Services", Haibo Wang, Jie Dong, Ketan Talaulikar, hantao, Ran Chen, 2023-12-18, This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for SRv6 services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 SIDs under the corresponding SRv6 locators, which are advertised as Colored prefixes. This allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. In data plane, dedicated transport label or SID for the inter-domain path is not needed, thus the encapsulation efficiency could be optimized. The existing IPv6 Address Family could be used for the advertisement of IPv6 Colored prefixes, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks. "BGP SR Policy Extensions for metric", KaZhang, Jie Dong, Ketan Talaulikar, 2023-12-18, 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, 2024-03-16, A Segment Routing (SR) Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI to advertise a candidate path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. "BGP Route Reflector with Next Hop Self", Kaliraj Vairavakkalai, Natrajan Venkataraman, 2024-03-16, The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains. "MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement", Chongfeng Xie, Guozhen Dong, Xing Li, Guoliang Han, Zhongfeng Guo, 2024-02-25, 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, 2024-03-16, Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the top-level BGP- Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). This document defines a new optional non-transitive BGP attribute called "MultiNexthop (MNH)" with IANA BGP attribute type code TBD, that can be used to carry an ordered set of one or more Nexthops in the same route, with forwaring information scoped on a per nexthop basis. Internet Area Working Group (intarea) ------------------------------------- "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", Donald Eastlake, Joe Abley, Yizhou Li, 2023-11-06, Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042. "Protocol Numbers for SCHC", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Pascal Thubert, 2023-10-12, This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. IOT Operations (iotops) ----------------------- "Comparison of CoAP Security Protocols", John Mattsson, Francesca Palombini, Malisa Vucinic, 2024-03-16, 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. "A summary of security-enabling technologies for IoT devices", Brendan Moran, 2023-10-23, The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies. IP Performance Measurement (ippm) --------------------------------- "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Greg Mirsky, Xiao Min, Wei Luo, Rakesh Gandhi, 2023-11-05, This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2023-11-09, 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. "A YANG Data Model for In-Situ OAM", Tianran Zhou, Jim Guichard, Frank Brockners, Srihari Raghavan, 2024-02-29, In-situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method to produce operational and telemetry information that may be exported using the in-band or out-of-band method. RFC9197 and RFC9326 discuss the data fields and associated data types for IOAM. This document defines a YANG module for the configuration of IOAM functions. "Integrity of In-situ OAM Data Fields", Frank Brockners, Shwetha Bhandari, Tal Mizrahi, Justin Iurman, 2023-10-16, 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 to ensure their security. This document describes the integrity protection of IOAM-Data-Fields. "Test Protocol for One-way IP Capacity Measurement", Len Ciavattone, Ruediger Geib, 2024-02-21, This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements. "Responsiveness under Working Conditions", Christoph Paasch, Randall Meyer, Stuart Cheshire, Will Hawkins, 2024-03-01, For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of latency, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. "IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option", Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, 2024-02-25, 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. "Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs)", Greg Mirsky, Joel Halpern, Xiao Min, Alexander Clemm, John Strassner, Jerome Francois, 2023-12-01, This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLO). These metrics, referred to as Precision Availability Metrics (PAM), are useful for defining and monitoring SLOs. For example, PAM can be used by providers and/or customers of an RFC XXXX Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. Note to the RFC Editor: Please update "RFC XXXX Network Slice" with the RFC number assigned to draft-ietf-teas-ietf-network-slices. "Quality of Outcome", Magnus Olden, Bjorn Teigen, 2024-01-10, This document describes a new network quality framework named Quality of Outcome (QoO). The QoO framework is unique among network quality frameworks in satisfying all the requirements layed out in "Requirements for a Network Quality Framework Useful for Applications, Users and Operators". The framework proposes a way of sampling network quality, setting network quality requirements and a formula for calculating the probability for the sampled network to satisfy network requirements. "Hybrid Two-Step Performance Measurement Method", Greg Mirsky, Wang Lingqiang, Guo Zhui, Haoyu Song, Pascal Thubert, 2023-10-04, Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. 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. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. "Alternate Marking Deployment Framework", Giuseppe Fioccola, Tianran Zhou, Thomas Graf, Massimo Nilo, Lin Zhang, 2024-01-03, This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security", Valery Smyslov, 2023-10-19, 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 it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is 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 also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations. "Group Key Management using IKEv2", Valery Smyslov, Brian Weis, 2024-02-26, 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. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE". "Announcing Supported Authentication Methods in IKEv2", Valery Smyslov, 2023-12-12, This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple different credentials to authenticate each other. "IKEv2 support for per-resource Child SAs", Antony Antony, Tobias Brunner, Steffen Klassert, Paul Wouters, 2024-03-18, This document defines two Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child SAs with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their crypto state or disable their packet replay protection. "IKEv2 Optional SA&TS Payloads in Child Exchange", Sandeep Kampati, Wei Pan, Paul Wouters, Bharath Meduri, Meiling Chen, 2024-01-12, 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 Profile", Daniel Migault, Tobias Guggemos, Carsten Bormann, David Schinazi, 2024-03-18, ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP. "Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC)", Daniel Migault, Tobias Guggemos, David Schinazi, 2024-03-18, This document describes an IKEv2 extension of for the ESP Header Compression (EHC) to agree on a specific ESP Header Compression (EHC) Context. Network Inventory YANG (ivy) ---------------------------- "A YANG Data Model for Network Inventory", Chaode Yu, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Phil Bedard, 2024-03-04, This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models. JSON Mail Access Protocol (jmap) -------------------------------- "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2024-02-28, This document specifies a data model for synchronizing calendar data with a server using JMAP. "JMAP for Sieve Scripts", Kenneth Murchison, 2024-02-07, This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. "JMAP Sharing", Neil Jenkins, 2024-03-18, This document specifies a data model for sharing data between users using JMAP. Future documents can reference this one when defining data types to support a consistent model of sharing. "JMAP for Contacts", Neil Jenkins, 2024-02-19, This document specifies a data model for synchronising contacts data with a server using JMAP. "Use of VAPID in JMAP WebPush", Daniel Gultsch, 2024-02-12, This document defines a method for JMAP servers to advertise their capability to authenticate WebPush notifications using the Voluntary Application Server Identification protocol. "JMAP REST Mapping", Joris Baum, Hans-Joerg Happel, 2024-02-19, This document specifies a REST Mapping for JMAP endpoints to impose fewer requirements on applications compared to conventional JMAP endpoints. "JMAP Guide for Migration and Data Portability", Joris Baum, Hans-Joerg Happel, 2024-02-19, JMAP (RFC8620) is a generic, efficient, mobile friendly and scalable protocol that can be used for data of any type. This makes it a good fit for migrations or data portability use cases that are focusing on data import and export. However, due to its large set of features, it is also quite complex, which makes it difficult to explore new application domains in practice. The goal of this document is to provide guidelines on implementing essential parts of JMAP for a much lower entry barrier and more efficient implementation of the protocol. "JMAP Migration and Portability Extensions", Joris Baum, Hans-Joerg Happel, 2024-02-19, JMAP (RFC8620) is a generic, efficient, mobile friendly and scalable protocol that can be used for data of any type. This makes it a good fit for migrations or data portability use cases. This extension adds additional features useful (but not limited to) those use cases. It adds a feature exposing details about the product, backend and environment of a JMAP server. It also adds a data model for extending the JMAP Response with log messages, particularly helpful for debugging. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Proof Token", Jeremie Miller, Michael Jones, David Waite, 2024-03-01, 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). "JSON Web Proof", Jeremie Miller, David Waite, Michael Jones, 2024-03-01, 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. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) 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", Jeremie Miller, Michael Jones, David Waite, 2024-03-01, The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof and JSON Web Key (JWK) specifications. It defines IANA registries for these identifiers. "Fully-Specified Algorithms for JOSE and COSE", Michael Jones, Orie Steele, 2024-02-28, This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, 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 all registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. Key Transparency (keytrans) --------------------------- "Key Transparency Architecture", Brendan McMillion, 2024-03-04, 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. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "Kerberos SPAKE Pre-Authentication", Nathaniel McCallum, Simo Sorce, Robbie Harwood, Greg Hudson, 2024-02-08, This document defines a new pre-authentication mechanism for the Kerberos protocol. The mechanism uses a password-authenticated key exchange to prevent brute-force password attacks, and may optionally incorporate a second factor. "Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication", Alexey Melnikov, 2024-03-04, This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey). Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John Mattsson, Francesca Palombini, 2024-01-22, This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. "Traces of EDHOC", Goeran Selander, John Mattsson, Marek Serafin, Marco Tiloca, Malisa Vucinic, 2024-01-27, This document contains some example traces of Ephemeral Diffie- Hellman Over COSE (EDHOC). "Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE", Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson, 2024-03-04, This document describes a procedure for authorizing enrollment of new devices using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). The procedure is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Header Protection for Cryptographically Protected E-mail", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2024-03-01, 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. The Header Protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. "Guidance on End-to-End E-mail Security", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2024-03-16, 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, 2024-03-01, 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 obsoletes RFC 4210 by including the updates specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. 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. Introducing CMP version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue and hashAlg for indicating a hash AlgorithmIdentifier in certConf messages. In addition to the changes specified in CMP Updates RFC 9480 this document adds support for management of KEM certificates. "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray, 2024-03-01, This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates on RFC 6712 specified in CMP Updates RFC 9480 Section 3 and obsoleted both documents. These updates introduce CMP URIs using a Well-known prefix. "Clarification of RFC7030 CSR Attributes definition", Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins, 2024-03-03, The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)", Sean Turner, Panos Kampanakis, Jake Massimo, Bas Westerbaan, 2024-03-03, Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known as Kyber, is a key-encapsulation mechanism (KEM). This document specifies algorithm identifiers and ASN.1 encoding format for ML-KEM in public key certificates. The encoding for public and private keys are also provided. [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA", Jake Massimo, Panos Kampanakis, Sean Turner, Bas Westerbaan, 2024-02-05, Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Module-Lattice-Based Digital Signatures (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 Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax", Hubert Kario, 2024-02-22, This document specifies additions and amendments to RFCs 7292 and 8018. It defines a way to use the Password Based Message Authentication Code 1, defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas Westerbaan, 2023-11-14, 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. "Related Certificates for Use in Multiple Authentications within a Protocol", Alison Becker, Rebecca Guthrie, Michael Jenkins, 2023-11-29, This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)", Russ Housley, John Gray, Tomofumi Okubo, 2024-02-06, The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. "Use of ML-KEM in the Cryptographic Message Syntax (CMS)", Julien Prat, Mike Ounsworth, Daniel Van Geest, 2024-03-02, The Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for the ML-KEM Algorithm are specified by NIST in [FIPS203-ipd] [EDNOTE: Change to [FIPS203] when it is published]. 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 KEMRecipientInfo as specified in [I-D.ietf-lamps-cms-kemri]. "Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, Sean Turner, 2024-03-04, The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM Algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM Algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in draft- ietf-lamps-cms-kemri. "X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions", Tirumaleswar Reddy.K, Jani Ekman, Daniel Migault, 2023-09-22, RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, JSON Web Token (JWT) and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5G System. "Updates to X.509 Policy Validation", David Benjamin, 2024-02-01, This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure which scaled exponentially in the worst case, leaving implementations vulnerable to denial-of- service attacks. "Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure and CMS", Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer, 2024-03-02, This document defines Post-Quantum / Traditional composite Key Encapsulation Mechanism (KEM) algorithms suitable for use within X.509, PKIX and CMS protocols. Composite algorithms are provided which combine ML-KEM with RSA-KEM and ECDH-KEM. The provided set of composite algorithms should meet most Internet needs. This document assumes that all component algorithms are KEMs, and therefore it depends on [I-D.ietf-lamps-rfc5990bis] and [I-D.ounsworth-lamps-cms-dhkem] in order to promote RSA and ECDH respectively into KEMs. For the purpose of combining KEMs, the combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri]. "Use of Remote Attestation with Certificate Signing Requests", Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, 2024-03-01, A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document defines a new PKCS#10 attribute attr-evidence and CRMF extension ext-evidence that allows placing any Evidence data, in any pre-existing format, along with any certificates needed to validate it, into a PKCS#10 or CRMF CSR. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). "Internationalized Email Addresses in X.509 Certificates", Alexey Melnikov, Wei Chuang, Corey Bonnell, 2024-02-13, This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280 and obsoletes RFC 8398. "Updates to Lightweight OCSP Profile for High Volume Environments", Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner, 2024-03-08, RFC 5019 defines a lightweight profile for OCSP that makes the protocol more suitable for use in high-volume environments. The lightweight profile specifies the mandatory use of SHA-1 when calculating the values of several fields in OCSP requests and responses. In recent years, weaknesses have been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is increasingly falling out of use even for non-security relevant use cases. This document obsoletes the lightweight profile as specified in RFC 5019 to instead recommend the use of SHA-256 where SHA-1 was previously required. An RFC 5019-compliant OCSP client is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future. "Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS)", Russ Housley, 2024-03-03, This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or part of a key derivation function. "No Revocation Available for X.509 Public Key Certificates", Russ Housley, Tomofumi Okubo, Joseph Mandel, 2024-03-16, X.509v3 public key certificates are profiled in RFC 5280. Short- lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate. "Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256", Russ Housley, 2024-03-18, This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS). The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier. "Online Certificate Status Protocol (OCSP) Nonce Extension", himanshu sharma, 2024-03-16, RFC 8954 imposed the size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document updates the maximum allowed length of Nonce to 128 octets. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document is a complete replacement for RFC 8954, obsoleting RFC 8954 and provides updated ASN.1 modules for OCSP, updating RFC 6960. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino, 2023-10-10, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal, Parantap Lahiri, 2024-02-19, This document describes how LISP reencapsulating 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 combination of both. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2024-01-14, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "LISP Virtual Private Networks (VPNs)", Victor Moreno, Dino Farinacci, 2023-09-19, This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. "LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci, 2023-11-06, 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 Predictive RLOCs", Dino Farinacci, Padma Pillay-Esnault, 2024-02-19, This specification describes a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs. "LISP EID Anonymity", Dino Farinacci, Padma Pillay-Esnault, Wassim Haddad, 2024-02-19, This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. "LISP Control-Plane ECDSA Authentication and Authorization", Dino Farinacci, Erik Nordmark, 2024-02-19, 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. "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay Hooda, 2023-09-26, 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). "Network-Hexagons:Geolocation Mapping 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, 2023-12-24, This specification describes functionality of LISP Nexagon networks. The network shares a joint vision of any number of producing sources, fleets, drones, and satellite, with any number of consuming clients, maps, GIS, and path planning copilots. Specifically it outlines: - joint-vision tiled enumeration geolocation language channels - addressing change notifications, overlaps, points of view, - freshness, privacy, localization, seamless context-switching, - via stateful driving of stateless models by EID location agents Safety applications of this network are: 1. Safety on-road: blockages & hazards beyond line of sight 2. Safety off-road: traffic-ability and varying risk degrees 3. Safety during disasters: fires, floods, snow, abrupt change The use of LISP enables the network to function securely uninterrupted while vision producers and consumers are constantly moving due to the connectivity-anchoring properties of LISP EIDs. Since EIDs are logical being based on mapping-system, it provides semantic-anchoring as well. Semantic joint vision consolidation uses H3 EID unicast and multicast. "LISP Map Server Reliable Transport", Balaji Venkatachalapathy, Marc Portoles-Comeras, Darrel Lewis, Isidor Kouvelas, Chris Cassar, 2023-10-20, 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 Distinguished Name Encoding", Dino Farinacci, 2023-12-28, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2023-11-26, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. Some use-cases can be geo-fencing and physically locating objects. Link State Routing (lsr) ------------------------ "A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane", Yingzhen Qu, Acee Lindem, Zhaohui Zhang, Helen Chen, 2024-01-18, This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. "A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane", Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Helen Chen, Jeff Tantsura, 2024-01-22, This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Huaimo Chen, Luay Jalil, Srinath Dontula, 2024-03-16, Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, 2023-12-30, This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RF 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 8920, and OSPF Flexible Algorithm. "YANG Model for OSPFv3 Extended LSAs", Acee Lindem, Sharmila Palani, Yingzhen Qu, 2024-02-02, This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. "Flooding Topology Minimum Degree Algorithm", Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2024-02-01, This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. "Area Proxy for IS-IS", Tony Li, Sarah Chen, Vivek Ilangovan, Gyan Mishra, 2024-01-18, Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. "IS-IS Topology-Transparent Zone", Huaimo Chen, Richard LI, Yi Yang, N Anil, Yanhe Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani, 2023-10-08, This document specifies a topology-transparent zone in an IS-IS area. A zone is a subset (block/piece) of an area, which comprises a group of routers and a number of circuits connecting them. It is abstracted as a virtual entity such as a single virtual node or zone edges mesh. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee Lindem, Peter Psenak, Yingzhen Qu, 2024-03-18, 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 AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended 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. The ISIS protocol supports a similar mechanism that is described in RFC 5130. "IS-IS YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Stephane Litkowski, Yingzhen Qu, 2024-03-03, 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 8919, 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, 2024-01-23, 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, 2023-12-19, 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. "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints", Shraddha Hegde, William Britto, Rajesh Shetty, Bruno Decraene, Peter Psenak, Tony Li, 2024-03-18, Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provide mechanisms to create constraint based paths in IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. "Algorithm Related IGP-Adjacency SID Advertisement", Shaofu Peng, Ran Chen, Ketan Talaulikar, Peter Psenak, 2023-12-05, Segment Routing architecture supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement. "YANG Data Model for OSPF SRv6", Zhibo Hu, Xuesong Geng, Syed Raza, Yingzhen Qu, Acee Lindem, 2024-03-03, 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, 2024-02-29, 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 Fast Flooding", Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Gunter Van de Velde, Tony Przygienda, 2024-02-15, Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. "IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White, Shraddha Hegde, Tony Przygienda, 2024-02-09, In dense topologies (such as data center fabrics based on the Clos and butterfly topologies, though not limited to those exclusively), IGP flooding mechanisms designed originally for sparse topologies can "overflood," or in other words generate too many identical copies of topology and reachability information arriving at a given node from other devices. This normally results in slower convergence times and higher resource utilization to process and discard the superfluous copies. The modifications to the flooding mechanism in the Intermediate System to Intermediate System (IS-IS) link state protocol described in this document reduce resource utilization significantly, while increaseing convergence performance in dense topologies. Beside reducing the extraneous copies it uses the dense topologies to "load-balance" flooding across different possible paths in the network to prevent build up of flooding hot-spots. Note that a Clos fabric is used as the primary example of a dense flooding topology throughout this document. However, the flooding optimizations described in this document apply to any arbitrary topology. "IGP Flexible Algorithms Reverse Affinity Constraint", Peter Psenak, Jakub Horn, Dhamija, 2024-03-18, An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. "IGP Unreachable Prefix Announcement", Peter Psenak, Clarence Filsfils, Stephane Litkowski, Dan Voyer, Dhamija, Shraddha Hegde, Gunter Van de Velde, Gyan Mishra, 2023-10-22, In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which 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, Chris Bowers, Les Ginsberg, 2024-02-13, New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. "Prefix Flag Extension for OSPFv2 and OSPFv3", Ran Chen, Detao Zhao, Peter Psenak, Ketan Talaulikar, Liyan Gong, 2024-01-25, Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix Attribute Flags Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. "Advertising Infinity Links in OSPF", Liyan Gong, Weiqiang Cheng, Changwang Lin, Acee Lindem, Ran Chen, 2024-03-17, This document proposes the method to advertise links as unreachable in OSPF. In some scenarios, there are requirements to advertise unreachable links in OSPF for purposes other than building the normal Shortest Path Tree. Link State Vector Routing (lsvr) -------------------------------- "BGP Link-State Shortest Path First (SPF) Routing", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2023-11-25, Many Massively Scaled Data Centers (MSDCs) have converged on simplified 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 Link State Vector Routing in Data Centers", Keyur Patel, Acee Lindem, Shawn Zandi, Gaurav Dawra, 2024-02-12, This document discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. "Layer-3 Discovery and Liveness", Randy Bush, Rob Austein, Russ Housley, Keyur Patel, 2024-02-11, 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. "A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF", Mahesh Jethanandani, Keyur Patel, 2023-10-10, This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. MAC Address Device Identification for Network and Application Services (madinas) -------------------------------------------------------------------------------- "Randomized and Changing MAC Address Use Cases", Jerome Henry, Yiu Lee, 2024-02-29, To limit the privacy issues created by the association between a device, its traffic, its location and its user, client and client OS vendors have started implementing MAC address rotation. When such a rotation 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 rotation purposes. This document lists various network environments and a set of network services that may be affected by such rotation. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. "Randomized and Changing MAC Address state of affairs", Juan Zuniga, Carlos Bernardos, Amelia Andersdotter, 2024-02-28, Users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on MAC addresses. There have been several initiatives within the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities to help coordinating standardization activities in these bodies. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP DiffServ Aware Credit Window Extension", Bow-Nan Cheng, Stan Ratliff, Lou Berger, 2024-03-18, 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. "DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng, David Wiggins, Lou Berger, Stan Ratliff, 2024-03-04, 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 defined in an extensible and reusable fashion. Their use will be mandated in other documents defining specific DLEP extensions. "DLEP Traffic Classification Data Item", Bow-Nan Cheng, Stan Ratliff, Lou Berger, 2024-03-18, This document defines a new Dynamic Link Exchange Protocol (DLEP) Data Item that is used to support traffic classification. Traffic classification information is used to identify 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", Stan Ratliff, Lou Berger, 2024-03-18, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- "QUIC-Aware Proxying Using HTTP", Tommy Pauly, Eric Rosenberg, David Schinazi, 2024-02-12, This document defines an extension to UDP Proxying over HTTP that adds specific optimizations for proxied QUIC connections. This extension allows a proxy to reuse UDP 4-tuples for multiple connections. It also defines a mode of proxying in which QUIC short header packets can be forwarded using an HTTP/3 proxy rather than being re-encapsulated and re-encrypted. "Proxying Bound UDP in HTTP", David Schinazi, Abhijit Singh, 2024-02-29, 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, 2023-10-19, 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. MBONE Deployment (mboned) ------------------------- "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2024-02-29, This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. "Multicast On-path Telemetry using IOAM", Haoyu Song, Mike McBride, Greg Mirsky, Gyan Mishra, Hitoshi Asaeda, Tianran Zhou, 2023-10-06, This document specifies the requirements of on-path telemetry for multicast traffic using In-situ OAM. While In-situ OAM is advantageous for multicast traffic telemetry, some unique challenges are present. This document provides the solutions based on the In- situ OAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. "Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang, Yisong Liu, Ying Cheng, Gyan Mishra, 2024-01-23, This document discusses multicast redundant ingress router failover issues, include global multicast and Service Provider Network MVPN use case. This document analyzes specification of global multicast and Multicast VPN Fast Upstream Failover and the 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, 2024-01-09, This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. Media Type Maintenance (mediaman) --------------------------------- "The 'haptics' Top-level Media Type", Yeshwant Muthusamy, Chris Ullrich, 2023-07-27, This memo serves to register and document the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration for a set of subtypes, which are representative of some existing subtypes already in use. "Media Types with Multiple Suffixes", Manu Sporny, Amy Guy, 2024-03-02, This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes. "Guidelines for the Definition of New Top-Level Media Types", Martin Duerst, 2024-03-03, This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. [RFC Editor, please remove this paragraph.] Comments and discussion about this document should be directed to media-types@ietf.org, the mailing list of the Media Type Maintenance (mediaman) WG. Alternatively, issues can be raised on GitHub at https://github.com/ ietf-wg-mediaman/toplevel. "Allowing Community Registrations in the Standards Tree", Mark Nottingham, 2023-10-11, Over time, it has become clear that there are media types which have the character of belonging in the standards tree (because they are not associated with any one vendor or person), but are not published by a standards body. This draft suggests an update to [RFC6838] to allow their registration. More Instant Messaging Interoperability (mimi) ---------------------------------------------- "More Instant Messaging Interoperability (MIMI) message content", Rohan Mahy, 2024-03-04, 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. Machine Learning for Audio Coding (mlcodec) ------------------------------------------- "Extension Formatting for the Opus Codec", Timothy Terriberry, Jean-Marc Valin, 2023-10-23, This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Architecture", Benjamin Beurdouche, Eric Rescorla, Emad Omara, Srinivas Inguva, Alan Duric, 2024-03-03, The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) provides a Group Key Agreement protocol for messaging applications. MLS is meant to protect against eavesdropping, tampering, message forgery, and provide Forward Secrecy (FS) and Post-Compromise Security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the delivery service, or the authentication service. "The Messaging Layer Security (MLS) Extensions", Raphael Robert, 2023-10-23, This document describes extensions to the Messaging Layer Security (MLS) 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/mlswg/mls-extensions. Media OPerationS (mops) ----------------------- "Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure", Renan Krishna, Akbar Rahman, 2024-03-04, This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, this document discusses those applications that run on devices having different form factors (such as different physical sizes and shapes) and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. This document discusses the expected behavior of XR applications which can be used to manage the traffic. In addition, the document discusses the service requirements of XR applications to be able to run on the network. "TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences", Lenny Giuliano, Chris Lenart, Rich Adam, 2024-02-20, As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/AR, live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi- destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology for content distribution. Media Over QUIC (moq) --------------------- "Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design", James Gruessing, Spencer Dawkins, 2023-09-29, This document describes use cases and requirements that guide the specification of a simple, low-latency media delivery solution for ingest and distribution, using either the QUIC protocol or WebTransport as transport protocols. "Media over QUIC Transport", Luke Curley, Kirill Pugin, Suhas Nandakumar, Victor Vasiliev, Ian Swett, 2024-03-04, 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. Multiprotocol Label Switching (mpls) ------------------------------------ "Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2024-02-29, Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system requests that the remote BFD peer transmits BFD control packets over the specified LSP. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2024-03-01, This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). "Refresh-interval Independent FRR Facility Protection", Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella, 2023-12-22, RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. "YANG Data Model for MPLS mLDP", Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura, 2024-02-29, This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "RFC6374 Synonymous Flow Labels", Stewart Bryant, George Swallow, Mach Chen, Giuseppe Fioccola, Greg Mirsky, 2021-03-05, RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as used in MPLS Transport Profile (MPLS-TP) networks. This document describes a method of extending RFC 6374 performance measurements from flows carried over MPLS-TP to flows carried over generic MPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multi-point to point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks. "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes", Shraddha Hegde, Mukul Srivastava, Kapil Arora, Samson Ninan, Xiaohu Xu, 2024-01-16, Egress Peer Engineering (EPE) is an application of Segment Routing to solve the problem of egress peer selection. The Segment Routing based BGP-EPE solution allows a centralized controller, e.g. a Software Defined Network (SDN) controller to program any egress peer. The EPE solution requires a node to program the PeerNode Segment Identifier(SID) describing a session between two nodes, the PeerAdj SID describing the link (one or more) that is used by sessions between peer nodes, and the PeerSet SID describing an arbitrary set of sessions or links between a local node and its peers. This document provides new sub-TLVs for EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and Traceroute procedures. "Performance Measurement for Segment Routing Networks with MPLS Data Plane", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Stefano Salsano, Mach Chen, 2024-02-09, Segment Routing (SR) leverages the source routing paradigm. SR is applicable to Multiprotocol Label Switching data plane (SR-MPLS) as specified in RFC 8402. RFC 6374 and RFC 7876 specify protocol mechanisms to enable efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks. RFC 9341 defines Alternate-Marking Method using Block Number (BN) for data correlation mechanism for packet loss measurement. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR-MPLS networks, for both links and end-to-end SR-MPLS paths including Policies. "A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow, Siva Sivabalan, 2023-11-06, In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modification of the existing MPLS control protocols. The existence of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. "Encapsulation For MPLS Performance Measurement with Alternate Marking Method", Weiqiang Cheng, Xiao Min, Tianran Zhou, Jinyou Dai, Yoav Peleg, 2024-02-27, This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. "Egress Validation in Label Switched Path Ping and Traceroute Mechanisms", Deepti Rathi, Shraddha Hegde, Kapil Arora, Zafar Ali, Nagendra Nainar, 2024-03-01, The MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for Segment Routing(SR) as defined in RFC 8287 is very useful to validate the control plane and data plane synchronization. In some environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A simple MPLS ping and traceroute mechanism allows traversing any path without validating the control plane state. RFC 8029 supports this mechanism with Nil Forwarding Equivalence Class (FEC). The procedures described in RFC 8029 mostly apply when the Nil FEC is used as an intermediate FEC in the label stack. When all labels in the label stack are represented using Nil FEC, it poses some challenges. This document introduces a new Type-Length-Value (TLV) as an extension to exisiting Nil FEC. It describes MPLS ping and traceroute procedures using Nil FEC with this extension to overcome these challenges. "Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks", Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar, 2024-02-19, The Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A network may consist of multiple IGP domains or multiple Autonomous Systems(ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains. This document describes mechanisms to facilitate LSP ping and traceroute in inter-AS/inter-domain SR- MPLS networks in an efficient manner with a simple Operations, Administration and Maintenance (OAM) protocol extension which uses data plane forwarding alone for forwarding echo replies on transit nodes. "BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Greg Mirsky, Gyan Mishra, Donald Eastlake, 2024-03-02, This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) and Segment Routing (SR) point-to- multipoint policies with SR-MPLS data plane. Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. "Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data", Tarek Saad, Kiran Makhijani, Haoyu Song, Greg Mirsky, 2024-02-10, This document presents a number of use cases that have a common need for encoding network action indicators and associated ancillary data inside MPLS packets. There has been significant recent interest in extending the MPLS data plane to carry such indicators and ancillary data to address a number of 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. "Requirements for Solutions that Support MPLS Network Actions", Matthew Bocci, Stewart Bryant, John Drake, 2024-03-04, This document specifies requirements for the development of MPLS network actions which affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating LSR (i.e. the LER). "mLDP Extensions for Multi-Topology Routing", IJsbrand Wijnands, Mankamana Mishra, Syed Raza, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko, 2023-08-02, Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP (Multipoint label distribution protocol) in a network that supports MTR and/or FA, mLDP is required to become topology and FA aware. This document specifies extensions to mLDP to support MTR with FA such that when building a Multipoint LSPs(Label Switched Paths) it can follow a particular topology and algorithm. "MPLS Network Actions Framework", Loa Andersson, Stewart Bryant, Matthew Bocci, Tony Li, 2024-01-24, This document specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer 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. Some of these actions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements found in "Requirements for MPLS Network Actions". "A YANG Model for MPLS MSD", Yingzhen Qu, Acee Lindem, Stephane Litkowski, Jeff Tantsura, 2024-01-24, This document defines a YANG data model augmenting the IETF MPLS YANG model to provide support for MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491. "MPLS Network Action (MNA) Sub-Stack Solution", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella, 2023-10-21, This document defines the MPLS Network Action (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional OAM information in the MPLS packet, or perform user-defined operations. This document addresses the MNA requirements specified in draft-ietf-mpls-mna-requirements. This document follows the MNA framework specified in draft-ietf-mpls- mna-fwk. "Deprecating the Use of Router Alert in LSP Ping", Kireeti Kompella, Ron Bonica, Greg Mirsky, 2024-03-01, The MPLS echo request and MPLS echo response messages, defined in RFC 8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP ping messages), are encapsulated in IP whose headers include a Router Alert Option (RAO). In actual deployments, the RAO was neither required nor used. Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM), and recommends against its use outside of controlled environments. Therefore, this document retires the RAO for MPLS OAM and updates RFC 8029 to remove the RAO from LSP ping message encapsulations. Furthermore, this document explains why RFC 7506 has been reclassified as Historic. Also, the use of an IPv6 loopback address (::1/128) as the IPv6 destination address for an MPLS echo request message is RECOMMENDED. "IANA Registry for the First Nibble Following a Label Stack", Kireeti Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson, Jie Dong, 2024-02-29, The goal of this memo is to create a new IANA registry (called the Post-stack First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. The memo offers a rationale for such a registry, describes how the registry should be managed, and provides some initial entries. Furthermore, this memo sets out some documentation requirements for registering new values. Finally, it provides some recommendations 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 memo, if published, would update RFC 4928. "Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes", Xiao Min, Shaofu Peng, Liyan Gong, Rakesh Gandhi, Carlos Pignataro, 2024-03-18, Path Segment is a type of Segment Routing (SR) segment, which is used to identify an SR path. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV definitions for Path Segment Identifiers. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, 2024-03-16, This document presents four YANG 1.1 modules. Three IETF modules, and one supporting IANA module. The three IETF modules are: ietf-tls-common, ietf-tls-client, and ietf-tls-server. The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers. The IANA module is: iana-tls-cipher-suite-algs. This module defines YANG enumerations providing support for an IANA-maintained algorithm registry. "RESTCONF Client and Server Models", Kent Watsen, 2024-03-16, This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by 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 (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-03-16 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, 2024-03-16, This document presents seven YANG 1.1 modules. Three IETF modules, and four supporting IANA modules. The three IETF modules are: ietf-ssh-common, ietf-ssh-client, and ietf-ssh-server. The "ietf-ssh-client" and "ietf-ssh-server" modules are the primary productions of this work, supporting the configuration and monitoring of SSH clients and servers. The four IANA modules are: iana-ssh-encryption-algs, iana-ssh-key- exchange-algs, iana-ssh-mac-algs, and iana-ssh-public-key-algs. These modules each define YANG enumerations providing support for an IANA-maintained algorithm registry. Editorial Note (To be removed by 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 draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-03-16 --> the publication date of this draft The "Relation to other RFCs" section Section 1.2 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.2 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix sections are to be removed prior to publication: * Appendix A.1. Initial Module for the "Encryption Algorithm Names" Registry * Appendix A.2. Initial Module for the "MAC Algorithm Names" Registry * Appendix A.3. Initial Module for the "Public Key Algorithm Names" Registry * Appendix A.4. Initial Module for the "Key Exchange Method Names" Registry * Appendix B. Change Log "NETCONF Client and Server Models", Kent Watsen, 2024-03-16, 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. Editorial Note (To be removed by 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 (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-03-16 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "A YANG Data Model for a Keystore and Keystore Operations", Kent Watsen, 2024-03-16, This document presents a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. "YANG Data Types and Groupings for Cryptography", Kent Watsen, 2024-03-16, This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. "A YANG Data Model for a Truststore", Kent Watsen, 2024-03-16, This document presents a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael Scharf, 2024-03-16, This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. "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, 2024-03-16, This document 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). Support is provided for HTTP/1.1, HTTP/2, and HTTP/3. "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Kent Watsen, Russ Housley, Sean Turner, 2022-03-02, This draft extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. "Subscription to Distributed Notifications", Tianran Zhou, Guangying Zheng, Eric Voit, Thomas Graf, Pierre Francois, 2023-10-06, 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", Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente, 2024-01-21, This document describes a UDP-based protocol for YANG notifications to collect data from network nodes. A shim header is proposed to facilitate the data streaming directly from the publishing process on network processor of line cards to receivers. The objective is to provide a lightweight approach to enable higher frequency and less performance impact on publisher and receiver processes compared to already established notification mechanisms. "Adaptive Subscription to YANG Notification", Qin WU, Wei Song, Peng Liu, Qiufang Ma, Wei Wang, Zhixiong Niu, 2023-12-12, This document defines a YANG data model and associated mechanism that enable adaptive subscription to a publisher's event streams. The periodic update interval for the event streams can be set adaptively. Applying these elements allows servers to automatically adjust the rate and volume of telemetry traffic sent from a publisher to receivers. "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li, 2024-03-01, 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, 2024-03-01, 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, Olof Hagsand, Hongwei Li, Per Andersson, 2024-03-01, 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 and DELETE operations, 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, 2024-03-01, 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 an inefficient mechanism for synchronization. This document specifies an extension to NETCONF 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, 2023-10-20, 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, 2024-03-01, 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. "NETCONF Extension to support Trace Context propagation", Roque Gagliano, Kristian Larsson, Jan Lindblad, 2024-01-11, 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, 2024-01-11, This document extends the RESTCONF protocol in order to support trace context propagation as defined by the W3C. "External Trace ID for Configuration Tracing", Jean Quilbeuf, Benoit Claise, Thomas Graf, Diego Lopez, Sun Qiong, 2024-01-11, 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, 2024-02-27, This document defines two YANG 1.1 modules to support the configuration of UDP clients and UDP servers. Network Modeling (netmod) ------------------------- "A YANG Data Model for Syslog Configuration", Joe Clarke, Mahesh Jethanandani, Clyde Wildes, Kiran Koushik, 2024-03-19, This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. "Common Interface Extension YANG Data Models", Robert Wilton, Scott Mansfield, 2024-01-30, 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, 2024-01-30, 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 orignating 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, 2024-01-14, 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, 2023-01-23, 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, 2024-03-01, 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 Semantic Versioning", Joe Clarke, Robert Wilton, Reshad Rahman, Balazs Lengyel, Jason Sterne, Benoit Claise, 2024-03-18, 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. "Node Tags in YANG Modules", Qin WU, Benoit Claise, Mohamed Boucadair, Peng Liu, Zongpeng Du, 2023-10-21, This document defines a method to tag nodes that are associated with the operation and management data in YANG modules. This method for tagging YANG nodes is meant to be used for classifying either data nodes or instances of data nodes from different YANG modules and identifying their characteristic data. Tags may be registered as well as assigned during the definition of the module, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future YANG data model writers; as such, this document updates RFC 8407. "System-defined Configuration", Qiufang Ma, Qin WU, Chong Feng, 2024-02-21, This document defines how a management client and server handle YANG- modeled configuration data that is defined by the server itself. The system-defined configuration can be referenced (e.g. leafref) by configuration explicitly created by a client. The Network Management Datastore Architecture (NMDA) defined in RFC 8342 is updated with a read-only conventional configuration datastore called "system" to hold system-defined configuration. As an alternative to clients explicitly copying referenced system- defined configuration into the target configuration datastore (e.g., ) so that the datastore is valid, a "resolve-system" parameter is defined to allow the server acting as a "system client" to copy referenced system nodes automatically. This solution enables clients manipulating the target configuration datastore (e.g., ) to reference nodes defined in , override system- provided values, and configure descendant nodes of system-defined configuration. This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040. "Extensions to the Access Control Lists (ACLs) YANG Model", Oscar de Dios, Samier Barguil, Mohamed Boucadair, Qin WU, 2024-01-30, RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. 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, 2024-02-28, This memo provides guidelines for authors and reviewers of specifications containing YANG modules, 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, 2024-03-18, This document defines a way to formally document existing behavior, implemented by servers in production, on the immutability of some system configuration 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 existing behavior, not proscriptive, dictating server behavior. Network File System Version 4 (nfsv4) ------------------------------------- "Extending the Opening of Files in NFSv4.2", Thomas Haynes, Trond Myklebust, 2024-03-18, The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This delegation provides the client the right to authoritatively cache metadata on the file locally. This document presents several extensions for both the opening and delegating of the file to the client. This document extends both RFC8881 and RFC7863. "Internationalization for the NFSv4 Protocols", David Noveck, 2023-11-20, 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. "Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices", Christoph Hellwig, Chuck Lever, Sorin Faibish, David Black, 2024-01-10, This document specifies how to use the Parallel Network File System (pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, 2023-12-20, 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 subsequently. 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 (nmrg) ------------------------- "Network Digital Twin: Concepts and Reference Architecture", Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed Boucadair, Christian Jacquenet, 2024-03-04, 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 and realize efficient and cost effective data driven network management, and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses the benefits and key challenges of such technology. "Research Challenges in Coupling Artificial Intelligence and Network Management", Jerome Francois, Alexander Clemm, Dimitri Papadimitriou, Stenio Fernandes, Stefan Schneider, 2024-03-04, This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require to couple 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 network 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. "Challenges and Opportunities in Management for Green Networking", Alexander Clemm, Cedric Westphal, Jeff Tantsura, Laurent Ciavaglia, Carlos Pignataro, Marie-Paule Odini, 2023-12-30, Reducing humankind's environmental footprint and making technology more 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. Methods to make networking technology itself "greener" and to manage and operate networks in ways that reduces their environmental footprint without impacting their utility therefore 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. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2023-11-06, 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, 2023-09-27, 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. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2023-09-27, 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, 2023-09-27, 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, 2023-09-27, 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, 2023-09-27, 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, 2023-09-27, 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, 2023-09-27, 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, 2023-09-27, 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. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2023-12-15, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention for identifying, naming, assigning, and managing persistent resources in the legal domain. This specification is published to allow adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain. This specification is an independent submission to the RFC series. It is not a standard, and does not have the consensus of the IETF. "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, 2024-03-01, 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. "OSPF Abnormal State Information", Huaimo Chen, 2024-01-31, This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2024-01-10, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2024-01-10, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 2023-09-27, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 2023-09-27, This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. "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. "Explicit Congestion Notification for the Stream Control Transmission Protocol", Randall Stewart, Michael Tuexen, 2023-10-20, This document describes the addition of the Explicit Congestion Notification (ECN) to the Stream Control Transmission Protocol (SCTP). "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen, 2024-01-07, FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, 2024-01-10, This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "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. "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen, 2024-01-10, This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "An Extension Language for the DNS", John Levine, Paul Vixie, 2024-02-04, Adding new RRTYPEs to the DNS has required that DNS servers and provisioning software be upgraded to support each new RRTYPE in Master files. This document defines a DNS extension language intended to allow most new RRTYPEs to be supported by adding entries to configuration data read by the DNS software, with no software changes needed for each RRTYPE. "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. "The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.", Huaimo Chen, 2023-10-08, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. "Extensible Provisioning Protocol (EPP) RESTful Transport", Maarten Wullink, Marco Davids, 2024-02-15, This document describes RESTful EPP (REPP), a data format agnostic, REST based Application Programming Interface (API) for the Extensible Provisioning Protocol [RFC5730]. REPP enables the development of a stateless and scalable EPP service. This document includes a mapping of [RFC5730] [XML] EPP commands to a RESTful HTTP based interface. Existing semantics as defined in [RFC5731], [RFC5732] and [RFC5733] are retained and reused in RESTful EPP. "JSON Hypertext Application Language", Mike Kelly, 2023-10-19, This document proposes a media type for representing resources and their relations with hyperlinks. "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, S. Kippe, 2023-12-19, 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, 2023-10-05, 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. "QoS-level aware Transmission Protocol (QTP) for virtual networks", Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan, 2023-10-01, This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. "Remote APDU Call Secure (RACS)", Pascal Urien, 2024-02-25, This document describes the Remote APDU Call Protocol Secure (RACS) protocol, dedicated to Grid of Secure Elements (GoSE). These servers host Secure Elements (SE), i.e. tamper resistant chips offering secure storage and cryptographic resources. Secure Elements are microcontrollers whose chip area is about 25mm2; they deliver trusted computing services in constrained environments. RACS supports commands for GoSE inventory and data exchange with secure elements. It is designed according to the representational State Transfer (REST) architecture. RACS resources are identified by dedicated URIs. An HTTP interface is also supported. An open implementation [OPENRACS] is available (https://github.com/purien) for various OS. "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, 2024-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, 2023-09-27, This document collects some idea for a next generation of the Reliable Server Pooling framework. "Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen, Autumn Liu, Mehmet Toy, Vic liu, 2024-01-10, This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). "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, 2023-12-24, 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, 2024-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.21. "Just because it's an Internet-Draft doesn't mean anything... at all...", Warren Kumari, 2023-10-22, Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)", Thomas Dreibholz, 2023-09-27, 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. "Correlation of multiple responses of forked INVITES in Back to Back User Agents", Roland Jesske, 2024-03-04, This document describe how a correlation of multiple responses of a forked INVITE in Back to Back User Agents can apply. "Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen Cheng, Peng Wang, Tong Duan, 2023-10-01, Service Function Chain architecture leads to more adaptive network nodes. It allows splitting the network function into fine-grained build blocks --- service function, and combining the network functions into service function chain to formulate complicated services. Further, the service function chain should be instantiated by selecting the optimal instance from the candidates for each service function in it. This document discusses the required components during the instantiation of service function chain in the network. "Simplemux. A generic multiplexing protocol", Jose Saldana, 2024-01-02, The high amount of small packets present in nowaday's networks results in a low efficiency, as the size of both the headers and the payload in these packets can be comparably large, often falling within the same order of magnitude. In some situations, multiplexing (i.e. aggregating) a number of small packets into a bigger one is desirable to improve the efficiency. For example, a number of small packets can be sent together between a pair of machines if they share a common network path. This may happen between machines in different locations or even inside a datacenter with a number of servers hosting virtual machines. The traffic profile can be shifted from small to larger packets, thus reducing the network overhead and the number of packets per second to be managed by intermediate devices. This document describes Simplemux, a protocol able to encapsulate a number of packets belonging to different protocols into a single packet. Small headers (separators) are added at the beginning of each multiplexed packet, including some flags, the packet length and a "Protocol" field. The presence of this "Protocol" field allows it to aggregate packets belonging to any protocol (the "multiplexed packets"), in a single packet belonging to other (or the same) protocol (the "tunneling protocol"). To reduce the overhead, the size of the multiplexing headers is kept very low (it may be a single byte when multiplexing packets of small size). "Multiple Upstream Interface Support for IGMP/MLD Proxy", Hitoshi Asaeda, Luis Contreras, 2024-03-03, This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface can be selected based on multiple criteria, such as the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described. "SMTP Service Extension for Client Identity", William Storey, 2023-11-29, This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CLIENTID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. "PCE-initiated IP Tunnel", Xia Chen, Hang Shi, Zhenbin Li, 2024-01-10, This document specifies a set of extensions to PCEP to support PCE- initiated IP Tunnel to satisfy the requirement which is introduced in [I-D.li-spring-tunnel-segment]. The extensions include the setup, maintenance and teardown of PCE-initiated IP Tunnels, without the need for local configuration on the PCC. "PCEP extensions for Distribution of Link-State and TE Information", Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, 2024-02-18, In order to compute and provide optimal paths, a 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. "Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan, Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2023-10-01, The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP) bases on the idea of "hop-by-hop routing forwarding, multi-backup next hop" and combines with the phenomena that water flows from higher place to lower. NP-MNRP defines a metric named as node potential, which is based on hop count and the actual link bandwidth, and calculates multiple next-hops through the potential difference between the nodes. "Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix", Naoki Matsuhira, 2023-10-03, 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, 2023-10-03, 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. "OAuth 2.0 Web Message Response Mode", Toru Yamaguchi, Nat Sakimura, Nov Matake, 2023-11-08, This specification defines a new response mode for RFC6749 that uses HTML5 Web Messaging (a.k.a window.postMessage()) instead of the redirect for the Authorization Response from the Authorization Endpoint. It defines two modes: simple mode and relay mode. Relay mode can be used to protect the access token in the implicit grant case by confining it within the origins of authorization server or resource server and preventing it from being read by the client. "BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu, 2023-10-15, This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed. "Generic Multicast Router Election on LAN's", IJsbrand Wijnands, Pierre Pfister, Zhaohui Zhang, 2023-10-19, When a host is connected to multiple multicast capable routers, each of these routers is a candidate to process the multicast flow for that LAN, but only one router should be elected to process it. This document proposes a generic multicast router election mechanism using Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) that can be used by any Multicast Overlay Signalling Protocol (MOSP). Having such generic election mechanism removes a dependency on Protocol Independent Multicast (PIM). "Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira, 2023-10-03, 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, 2023-10-03, 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, 2023-10-03, 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, 2023-10-03, 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, 2023-10-03, 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, 2023-10-03, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2023-10-03, 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. "Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets", Michael Tuexen, Randall Stewart, 2024-03-03, RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification of the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets for which the verification tag can not be checked. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2023-10-03, 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, 2023-12-18, 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. "SSH Agent Protocol", Damien Miller, 2024-02-27, This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. "Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2024-01-10, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for determining parent child relations and exchanging the information between a parent and a child PCE in a hierarchical PCE system. "PCEP Link State Abstraction", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2024-01-10, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to abstract its domain information to its parent for supporting a hierarchical PCE system. "Static PCEP Link State", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2024-01-10, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links without running IGP and for a PCE to build a TED based on the information received. "MVPN/EVPN C-Multicast Routes Enhancements", Zhaohui Zhang, Robert Kebler, Wen Lin, Eric Rosen, 2024-03-17, [RFC6513] and [RFC6514] specify procedures for originating, propagating, and processing "C-multicast routes". However, there are a number of MVPN use cases that are not properly or optimally handled by those procedures. This document describes those use cases, and specifies the additional procedures needed to handle them. Some of the additional procedures are also applicable to EVPN SMET routes [RFC9251]. "Fast HIP Host Mobility", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2023-12-07, 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, 2023-12-24, 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-02-21, This document describes the MISP taxonomy format, a simple JSON format used to represent machine tags (also known as triple tags) vocabularies. A public directory, known as MISP taxonomies, is available and utilizes the MISP taxonomy format. These taxonomies are employed to classify cybersecurity events, threats, suspicious events, or indicators. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application", Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, 2024-01-23, This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson). "BIER in BABEL", Zheng Zhang, Tony Przygienda, 2024-01-23, BIER introduces a novel multicast architecture. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per- flow state. Babel defines a distance-vector routing protocol that operates in a robust and efficient fashion both in wired as well as in wireless mesh networks. This document defines a way to carry necessary BIER signaling information in Babel. "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff Tantsura, 2023-12-28, 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, 2023-12-14, 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. "Mobility Capability Negotiation", Zhiwei Yan, Tianji Jiang, Jianfeng Guan, Tao Huang, Jong-Hyouk Lee, 2024-02-22, Mobile peers exchange signals with networks, for both wireline and wireless domains, to negotiate capabilities for mobile registration, connection management, session establishment, service provisioning, etc. Generally, mobility capabilities include the supported and provisioned resources along with associated protocols for certain mobility management scenarios. While devices in the mobile wireline (IP) domain would mostly focus on the IP-related negotiation, devices in the wireless domain, e.g., the 5G system (5GS), embrace both mobile IP-related resources as well as wireless-specific capabilities. Regarding both the mobile-IP and wireless domains, we have generalized two protocol categories for mobility capability negotiation & management, i.e., the host-initiated category that involves the direct & active engagement of mobile end devices vs. the network-based category over which mobile endpoints play almost no role in the process. The classification and then the application of the two categories help us analyze the mobility capability negotiation for both the mobile IPv6 and the 3GPP 5G system. The comparison of the capability negotiation under both the Home-Routed (HR) and the Local BreakOut (LBO) roaming cases in 5GS further reflects the feasibility of the protocol dichotomy. "BGP Extension For L3VPN Performance Monitoring", Jiajia Fan, Zhenbin Li, Shunwan Zhuang, 2024-03-03, This document describes a new VT address family in BGP to exchange information required for apply performance monitoring in MPLS/BGP VPN, as described in [I-D.dong-l3vpn-pm-framework]. "ISP Location in DNS Queries", Pan Lanlan, Yu Fu, Cuicui Wang, 2024-01-15, Nowadays, many authoritative servers support GeoIP feature, they guess the client's geolocation by the client subnet of EDNS Client Subnet (ECS) or by the source IP address of DNS query, return tailor DNS response based on the client's geolocation. However, ECS raises some privacy concerns because it leaks client subnet information on the resolution path to the authoritative server. This document describes an improved GeoIP solution, defines an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, tries to find the right balance between privacy improvement and user experience optimization. EIL is defined to convey isp location < COUNTRY, AREA, ISP > information that is relevant to the DNS message. It will directly provide sufficient information for the GeoIP-enabled authoritative server as ECS, decide the response without guessing client's geolocation. "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, Sandra Cespedes, 2024-02-08, This document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular networks. An optimized Address Registration and a multihop Duplicate Address Detection (DAD) mechanism are performed for having operation efficiency and also saving both wireless bandwidth and vehicle energy. In addition, three new ND options for prefix discovery, service discovery, and mobility information report are defined to announce the network prefixes and services inside a vehicle (i.e., a vehicle's internal network). "DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based Vehicular Networks", Jaehoon Jeong, Yoseop Ahn, Sejun Lee, J., PARK, 2024-02-08, This document specifies an autoconfiguration scheme for device discovery and service discovery in IP-based vehicular networks. Through the device discovery, this document supports the global (or local) DNS naming of Internet-of-Things (IoT) devices, such as sensors, actuators, and in-vehicle units. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's model information in wired and wireless target networks (e.g., vehicle, road network, home, office, shopping mall, and smart grid). Through the service discovery, IoT users (e.g., drivers, passengers, home residents, and customers) in the Internet (or local network) can easily identify each device for monitoring and remote-controlling it in a target network. "Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems.", Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni, Julien Meuric, 2024-01-23, This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1 and its extensions and G.872. "OSPF Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2024-01-10, This document presents extensions to the Open Shortest Path First (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) links. "ISIS Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2024-01-10, This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links. "BGP Logical Link Discovery Protocol (LLDP) Peer Discovery", Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu, 2024-01-04, 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. "Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Charles Perkins, John Dowdell, Lotte Steenbrink, Victoria Pritchard, 2024-03-03, The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. "Short-Lived Certificates for Secure Telephone Identity", Jon Peterson, 2023-11-09, When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. "NEAT Sockets API", Thomas Dreibholz, 2024-03-01, 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. "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak, 2023-12-17, This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. "IPv6 is Classless", Nicolas Bourbaki, 2023-10-05, 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. "BFD in Demand Mode over a Point-to-Point MPLS LSP", Greg Mirsky, 2023-11-09, This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. "BGP Signaled MPLS Namespaces", Kaliraj Vairavakkalai, Jeyananth Jeganathan, Praveen Ramadenu, Israel Means, 2023-10-20, 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. "PIM Proxy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Ali Sajassi, Mankamana Mishra, 2023-10-11, Ethernet Virtual Private Networks are becoming prevalent in Data Centers, Data Center Interconnect (DCI) and Service Provider VPN applications. One of the goals that EVPN pursues is the reduction of flooding and the efficiency of CE-based control plane procedures in Broadcast Domains. Examples of this are Proxy ARP/ND and IGMP/MLD Proxy. This document complements the latter, describing the procedures required to minimize the flooding of PIM messages in EVPN Broadcast Domains, and optimize the IP Multicast delivery between PIM routers. "Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses", Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske, 2023-12-29, 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 , 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. "IPv6-only Terminology Definition", Jordi Martinez, 2023-10-23, This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri, 2024-02-19, This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network. "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. "IPv6 Source Routing for ultralow Latency", Andreas Foglar, Theodoros Rokkas, Marcin Godzina, Mikhail Khokhlov, 2023-11-13, This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for ultralow latency source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial net- works or other networks requiring very low latency. "MISP galaxy format", Alexandre Dulaunoy, Andras Iklody, Deborah Servili, 2023-12-24, This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing. "MISP object template format", Alexandre Dulaunoy, Andras Iklody, 2023-12-24, This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format. "Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP", Greg Mirsky, Yanhua Zhao, Gyan Mishra, Ron Bonica, 2024-01-09, This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path. "A YANG Data Model for Client-layer Tunnel", Chaode Yu, Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2023-10-09, 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. "DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet, Michael Behringer, 2024-01-05, DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. "CoAP: Non-traditional response forms", Carsten Bormann, Christian Amsuess, 2024-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, 2023-11-10, 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, 2023-10-16, This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. "Firewall and Service Tickets", Tom Herbert, 2023-10-07, This document describes the Firewalls and Service Tickets (FAST) protocol. This is a generic and extensible protocol for hosts to signal network nodes to request services or to gain admission into a network. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied (in the latter case the ticket serves as a service profile). Applications request tickets from a local agent in their network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to packets. A single ticket may provide both firewall and service ticket information and semantics. Tickets are sent in IPv6 Hop-by-Hop options. "A feature freezer for the Concise Data Definition Language (CDDL)", Carsten Bormann, 2024-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, 2024-01-20, 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. "Hierarchy of IP Controllers (HIC)", Zhenbin Li, Dhruv Dhody, Huaimo Chen, 2023-10-22, This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with other protocols like BGP, Path Computation Element Communication Protocol (PCEP), and other YANG-based protocols to provide end to end dynamic services spanning multiple domains and controllers (e.g. Layer 3 Virtual Private Network (L3VPN), Seamless MPLS etc). "VXLAN-GPE Encapsulation for In Situ OAM (IOAM) Data", Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel, 2024-03-01, In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in VXLAN-GPE. "EVPN All Active Usage Enhancement", Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ White, 2023-11-22, A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links. "EVPN VXLAN Bypass VTEP", Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ White, 2023-11-22, A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability. "In-situ OAM raw data export with IPFIX", Mickey Spiegel, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, 2024-02-12, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses how In-situ Operations, Administration, and Maintenance (IOAM) information can be exported in raw, i.e. uninterpreted, format from network devices to systems, such as monitoring or analytics systems using IPFIX. "ICANN Registrar Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2023-10-05, 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. "IS-IS Flooding Reduction in MSDC", Xiaohu Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma, 2024-01-30, IS-IS is a commonly used routing protocol in MSDC (Massively Scalable Data Center) networks where CLOS is the most popular topology. In a CLOS topology, each IS-IS router would receive multiple copies of the same LSP (Link State Packet) from multiple IS-IS neighbors. Moreover, two IS-IS neighbors may send each other the same LSP simultaneously. The unnecessary link-state information flooding results in a large waste of resources for IS-IS routers, as there are too many neighbors for each router. To address this scaling problem, this document introduces some extensions to the IS-IS protocol. These extensions aim to significantly reduce the IS-IS flooding within MSDC networks, which can greatly improve the scalability of such networks. "IMAP Service Extension for Client Identity", Deion Yu, 2023-11-29, This document defines an Internet Message Access Protocol (IMAP) service extension called "CLIENTID" which provides a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. "The IPv6 Tunnel Payload Forwarding (TPF) Option", Ron Bonica, Yuji Kamite, Luay Jalil, Yifeng Zhou, Gang Chen, 2024-01-15, This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. "Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space", Cheng Li, Hang Shi, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2024-01-25, 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 or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a generic mechanism for a PCC to 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 to-be-defined identifier that can be allocated and managed by the PCE. "IGP Extensions for Scalable Segment Routing based Virtual Transport Network (VTN)", Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Stewart Bryant, 2023-10-23, Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used to support one or a group of VPN+ services. In the context of network slicing, a VTN could be instantiated as a network resource partition (NRP). This document specifies the IGP mechanisms with necessary extensions to advertise the associated topology and resource attributes for scalable Segment Routing (SR) based NRPs. Each NRP can have a customized topology and a set of network resources allocated from the physical network. Multiple NRPs may shared the same topology, and multiple NRPs may share the same set of network resources on some network segments. This allows flexible combination of the network topology and network resource attributes to build a relatively large number of NRPs with a relatively small number of logical topologies. A group of resource-aware SIDs and SRv6 Locators can be assigned to each NRP. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and Segment Routing with IPv6 data plane (SRv6). This document also describes the mechanism of using dedicated NRP ID in the data plane instead of the per-NRP resource-aware SIDs and SRv6 Locators to further reduce the control plane and data plane overhead of maintaining a large number of NRPs. "Multi-Site Solution for Ethernet VPN (EVPN) Overlay", Lukas Krattiger, Ayan Banerjee, Ali Sajassi, Krishnaswamy Ananthamurthy, R. Sharma, 2023-11-06, This document describes the procedures for interconnecting two or more Network Virtualization Overlays (NVOs) with EVPN via NVO over IP-only network. The solution interconnects Ethernet VPN network by using NVO with Ethernet VPN (EVPN) to facilitate the interconnect in a scalable fashion. The motivation is to support extension of Layer-2 and Layer-3, Unicast & Multicast, VPNs without having to rely on typical Data Center Interconnect (DCI) technologies like MPLS/ VPLS. The requirements for the interconnect are similar to the ones specified in [RFC7209], "Requirements for Ethernet VPN (EVPN)". In particular, this document describes the difference of the Gateways (GWs) procedure and combined functionality from [RFC9014], "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks" and and [I-D.ietf-bess-evpn-ipvpn-interworking], "EVPN Interworking with IPVPN", which this solution is interoperable to. This document updates and replaces all previous version of Multi-site EVPN based VXLAN using Border Gateways (draft- sharma-multi-site-evpn). "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark, 2023-10-23, This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. "Guidelines for Security Policy Translation in Interface to Network Security Functions", Jaehoon Jeong, Patrick Lingga, Jinhyuk Yang, 2024-02-07, This document proposes the guidelines for security policy translation in Interface to Network Security Functions (I2NSF) Framework. When I2NSF User delivers a high-level security policy for a security service, Security Policy Translator in Security Controller translates it into a low-level security policy for Network Security Functions (NSFs). For this security policy translation, this document specifies the relation between a high-level security policy based on the Consumer-Facing Interface YANG data model and a low-level security policy based on the NSF-Facing Interface YANG data model. Also, it describes an architecture of a security policy translator along with an NSF database, and the process of security policy translation with the NSF database. "MPLS Network Actions using Post-Stack Extension Headers", Haoyu Song, Tianran Zhou, Loa Andersson, Zhaohui Zhang, Rakesh Gandhi, 2023-10-11, Motivated by the need to support multiple in-network services and functions in an MPLS network (a.k.a. MPLS Network Actions or MNA), this document describes a generic and extensible method to encapsulate MNA instructions as well as possible ancillary data in an MPLS packet. All the post-stack MNAs are encapsulated in a structure called Post-stack Action Header (PAH). A PAH is composed of a common header plus a chain of extension headers with each serving as a container for an MNA. The encapsulation method allows chaining multiple post-stack extension headers and provides the means to enable fast access to them as well as the original upper layer headers. We confine this document to the solution of PAH encoding and leave the specification of PAH indicator to the overall MNA solution. We show how PAH can be used to support several new MNAs as a generic post-stack mechanism. "Flexible Session Protocol", Jun-an Gao, 2023-10-17, 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 "Access Extensions for ANCP", Hongyu Li, Thomas Haag, Birgit Witschurke, 2024-03-18, The purpose of this document is to specify extensions to ANCP (Access Node Control Protocol) (RFC6320) to support PON as described in RFC6934 and some other DSL Technologies including G.fast. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. "Discovery of OSCORE Groups with the CoRE Resource Directory", Marco Tiloca, Christian Amsuess, Peter van der Stok, 2024-03-04, 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. "Alternative Elliptic Curve Representations", Rene Struik, 2022-01-21, This document specifies how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form and illustrates how this can be used to carry out elliptic curve computations leveraging existing implementations and specifications of, e.g., ECDSA and ECDH using NIST prime curves. We also provide extensive background material that may be useful for implementers of elliptic curve cryptography. "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola, Yisong Liu, Mauro Cociglio, Ran Pang, Lixia Xiong, Shinyoung Lee, Weidong Li, 2023-11-23, 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, 2024-01-10, 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. "BMP for BGP Route Leak Detection", Yunan Gu, China Telecom, Di Ma, Nan Geng, Shunwan Zhuang, 2024-03-03, According to Route-Leak Problem Definition [RFC7908], Route leaks refer to the case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to prevent the happening of BGP [RFC4271] route leaks. However, the real-time route leak detection if any occurs is important as well, and serves as the basis for leak mitigation. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks at the prefix level. "Architecture for Use of BGP as Central Controller", Yujia Luo, Liang Ou, Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li, 2024-01-31, BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow across the network. This document describes some reference architectures for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality. "Flowspec Indirection-id Redirect for SRv6", Gunter Van de Velde, Keyur Patel, Zhenbin Li, Huaimo Chen, 2024-01-10, This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. "Framework for In-situ Flow Information Telemetry", Haoyu Song, Fengwei Qin, Huanan Chen, Jaewhan Jin, Jongyoon Shin, 2023-10-23, As network scale increases and network operation becomes more sophisticated, existing Operation, Administration, and Maintenance (OAM) methods are no longer sufficient to meet the monitoring and measurement requirements. Emerging data-plane on-path telemetry techniques, such as IOAM and AltMrk, which provide high-precision flow insight and issue notifications in real time can supplement existing proactive and reactive methods that run in active and passive modes. They enable quality of experience for users and applications, and identification of network faults and deficiencies. This document describes a reference framework, named as In-situ Flow Information Telemetry, for the on-path telemetry techniques. The high-level framework outlines the system architecture for applying the on-path telemetry techniques to collect and correlate performance measurement information from the network. It identifies the components that coordinate existing protocol tools and telemetry mechanisms, and addresses deployment challenges for flow-oriented on- path telemetry techniques, especially in carrier networks. The document is a guide for system designers applying the referenced techniques. It is also intended to motivate further work to enhance the OAM ecosystem. "SRv6 and MPLS interworking", Swadesh Agrawal, Clarence Filsfils, Dan Voyer, Gaurav Dawra, Zhenbin Li, Shraddha Hegde, 2024-03-04, This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. "IPv6 Formal Anycast Addresses and Functional Anycast Addresses", Mark Smith, 2024-02-22, Currently, IPv6 anycast addresses are chosen from within the existing IPv6 unicast address space, with the addresses nominated as anycast addresses through configuration. An alternative scheme would be to have a special class of addresses for use as anycast addresses. This memo proposes a distinct general anycast addressing class for IPv6, and a more specific scheme for functional anycast addresses. "Constrained Application Protocol (CoAP): Corrections and Clarifications", Carsten Bormann, 2024-02-28, 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. "CoRE Resource Directory Extensions", Christian Amsuess, 2024-03-04, A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. "General Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw, 2024-03-03, 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, 2023-10-23, 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. "Proxy MAC-IP Advertisement in EVPNs", Ryan Bickhart, Wen Lin, John Drake, Jorge Rabadan, Alton Lo, Patrice Brissette, 2024-03-04, This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. "Composite ML-DSA for use in Internet PKI", Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, 2024-03-04, This document defines Post-Quantum / Traditional composite Key Signaturem algorithms suitable for use within X.509, PKIX and CMS protocols. Composite algorithms are provided which combine ML-DSA with RSA, ECDSA, Ed25519, and Ed448. The provided set of composite algorithms should meet most X.509, PKIX, and CMS needs. "SRv6 Midpoint Protection", Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong Geng, Yisong Liu, Gyan Mishra, 2024-02-01, The current local repair mechanism, e.g., TI-LFA, allows the upstream neighbor of the failed node or link to fast re-route traffic around the failure. This mechanism does not work properly for SRv6 TE path after the failure happens in an endpoint node and IGP converges on the failure. This document defines midpoint protection for SRv6 TE path, which enables the upstream endpoint node of the failed node to perform the endpoint behavior for the faulty node and fast re-route traffic around the failure after IGP converges on the failure. "BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf, Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2023-10-20, The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854], BGP local-rib [RFC9069] and BGP adj-rib-out [RFC8671]. By monitoring these BGP RIB's the full state of the network is visible, but how route-policies affect the route propagation or changes BGP attributes is still not. This document describes a method of using BMP to record the trace data on how BGP routes are (not) changed under the process of route policies. "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde, 2023-10-19, 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. "Arm's Platform Security Architecture (PSA) Attestation Token", Hannes Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati, 2024-02-21, The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA 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. "JSON Web Token (JWT) Embedded Tokens", Rifaat Shekh-Yusef, Dick Hardt, Giuseppe De Marco, 2023-12-24, This specification defines a mechanism for embedding tokens into a JWT token. The JWT token and the embedded tokens are issued by one ore more issuers. "Enhanced AS-Loop Detection for BGP", Huanan Chen, Di Ma, Nan Geng, Shunwan Zhuang, Haibo Wang, 2024-03-03, Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. "Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, 2024-02-08, This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory. "IPv4 Extension Headers and Flow Label", Tom Herbert, 2024-02-22, This specification defines extension headers for IPv4 and an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. "Design of the native Cyberspace Map", Jilong Wang, Miao Congcong, Changqing An, Shuying Zhuang, 2023-11-12, This memo discusses the design of the native cyberspace map which is stable and flexible to describe cyberspace. Although we have accepted the cyberspace as a parallel new world, we even have not defined its basic coordinate system, which means cyberspace have no its basic space dimension till now. The objective of this draft is to illustrate the basic design methodology of the native coordinate system of cyberspace, and show how to design cyberspace map on this basis. "A Framework for Constructing Service Function Chaining Systems Based on Segment Routing", Yuanyang Yin, Cheng Li, Ahmed El Sawaf, Hongyi Huang, Zhenbin Li, 2024-03-01, Segment Routing (SR) introduces a versatile methodology for defining end-to-end network paths by encoding sequences of topological sub- paths, known as "segments". This architecture can be deployed over both MPLS and IPv6 data planes, offering a flexible routing solution. Service Function Chaining (SFC) supports the establishment of composite services through an ordered sequence of Service Functions (SFs) that are applied to packets or frames based on initial classification. SFC's implementation can utilize various underlying technologies, including the Network Service Header (NSH) and SR, to facilitate the creation and management of service chains. This document presents a comprehensive control framework for developing SFC architectures using Segment Routing. It explores control plane solutions for the distribution of service function instance routes and service function paths, as well as techniques for directing packets into specific service function chains. The discussion encompasses both theoretical foundations and practical considerations for integrating SR into SFC deployments. "Modern Network Unicode", Carsten Bormann, 2024-02-29, 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. "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu, 2023-10-08, This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path. "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. "BGP Request for Candidate Paths of SR TE Policies", Zhenbin Li, Qiangzhou Gao, Huaimo Chen, Yanhe Fan, Xufeng Liu, Lei Liu, 2023-10-22, An SR Policy is a set of candidate paths. The headend of an SR Policy may learn multiple candidate paths for an SR Policy via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document defines extensions to BGP for the headend to request BGP speaker (controller) for advertising the candidate paths. "Network Programming extension: SRv6 uSID instruction", Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Dan Voyer, Israel Meilik, Keyur Patel, Wim Henderickx, Prem Jonnalagadda, David Melman, Yisong Liu, Jim Guichard, 2023-12-13, The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: * The SRv6 Control Plane is leveraged without any change * The SRH dataplane encapsulation is leveraged without any change * Any SID in the SID list can carry micro segments * Based on the Compressed SRv6 Segment List Encoding in SRH "Describing Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2023-10-22, This document describes a machine-readable format for specifying the syntax of protocol data units within a protocol specification, known as an Augmented Packet Header Diagram. This comprises a consistently formatted packet header diagram, using a well-defined syntax, that is followed by structured explanatory text. The Augmented Packet Header Diagram format is designed to maintain human readability, while also supporting automated parser generation from protocol specification documents. This document is itself an example of how the format can be used. "SRv6 for Inter-Layer Network Programming", Liuyan Han, Jie Dong, Zongpeng Du, Minxue Wang, 2024-03-01, 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 an SRv6 based mechanism for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. A new SRv6 behavior called End.XU is introduced, which is a variant of the SRv6 End.X behavior. Instead of pointing to an interface with layer-3 adjacency, the End.XU behavior points to an underlay interface which connects to a remote layer-3 node via underlying links or connections that are invisible in the L3 network topology. The applicability of the End.XU behavior in typical inter- layer network programming scenarios is also illustrated. "Maintaining CCNx or NDN flow balance with highly variable data object sizes", David Oran, 2023-10-23, 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. "Framework for Cyberspace Resources Categorization", Jilong Wang, Congcong Miao, Shuying Zhuang, Qianli Zhang, Chengyuan Zhang, 2023-12-03, This memo presents the definition of cyberspace resource, and then discusses a classification framework for cyberspace resources. Cyberspace is widely applied in people's daily life and it is regarded as a new space, paralleled to the geographic space. There are various resources in cyberspace. However, they have not been systematically defined and classified. The objective of this draft is to present the deifinition of cyberspace resource and a standard classification framework, thus, supporting the unified resource storage and shares. "Lzip Compressed Format and the 'application/lzip' Media Type", Antonio Diaz, 2023-12-28, 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, 2023-12-04, 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, 2024-03-01, This document defines a generic stateless command-line interface for dealing with OpenPGP messages, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6", Xueshun Wang, Jinyou Dai, Weiqiang Cheng, Jianhua Liu, Feng Zhang, 2024-01-05, This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks. "Performance Measurement for Geneve", Xiao Min, Greg Mirsky, Santosh Pallagatti, 2023-10-12, This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. "A YANG Data Model for Client Signal Performance Monitoring", Chaode Yu, Haomian Zheng, Italo Busi, Zheng Yanlei, Victor Lopez, Oscar de Dios, 2024-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. "BGP-LS Extensions for Scalable Segment Routing based Enhanced VPN", Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, 2023-10-23, Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the resources and characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which can be used to support one or a group of VPN+ services. In the context of network slicing, a VTN could be instantiated as a network resource partition (NRP). This document specifies the BGP-LS mechanisms with necessary extensions to advertise the information of scalable Segment Routing (SR) based NRPs to a centralized network controller. Each NRP can have a customized topology and a set of network resources allocated from the physical network. Multiple NRPs may shared the same topology, and multiple NRPs may share the same set of network resources on specific network segments. This allows flexible combination of network topology and network resource attributes to build a large number of NRPs with a relatively small number of logical topologies. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). "Context-Aware Navigation Protocol for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Zeung Kim, 2024-03-18, This document proposes a Context-Aware Navigation Protocol (CNP) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CNP aims at the enhancement of driving safety through a light-weight driving information sharing method. The CNP protocol uses an IPv6 Neighbor Discovery (ND) option to convey driving information such as a vehicle's position, speed, acceleration/deceleration, and direction, and a driver's driving action (e.g., braking and accelerating). "Basic Support for Security and Privacy in IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, J., PARK, Tae Oh, 2024-02-08, This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks. "SRv6 Deployment Consideration", Hui Tian, Chongfeng Xie, Edmore Chingwena, Shuping Peng, Qiangzhou Gao, 2024-02-27, SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced. "Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang, Aijun Wang, Shunwan Zhuang, 2024-03-04, 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. "IETF Network Slice Topology YANG Data Model", Xufeng Liu, Jeff Tantsura, Igor Bryskin, Luis Contreras, Qin WU, Sergio Belotti, Reza Rokui, Aihua Guo, Italo Busi, 2024-03-01, An IETF 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 configuring customer intent topologies for network slices using IETF technologies defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-ietf-network-slices once it has been published. "Use of ALTO for Determining Service Edge", Luis Contreras, Sabine Randriamasy, Jordi Ros-Giralt, Danny Perez, Christian Rothenberg, 2023-10-13, Service providers are starting to deploy computing capabilities across the network for hosting applications such as AR/VR, vehicle networks, IoT, and AI training, among others. In these distributed computing environments, knowledge about computing and communication resources is necessary to determine the proper deployment location of each application. This document proposes an initial approach towards the use of ALTO to expose such information to the applications and assist the selection of their deployment locations. "MVPN and EVPN BUM Signaling with Controllers", Zhaohui Zhang, Rishabh Parekh, Zheng Zhang, Hooman Bidgoli, 2023-10-11, This document specifies optional procedures for BGP-MVPN and EVPN BUM signaling with controllers. When P2MP tunnels used for BGP-MVPN and EVPN BUM are to be signaled from controllers, the controllers can learn tunnel information (identifier, root, leaf) by participating BGP-MVPN and EVPN BUM signaling, instead of relying on ingress PEs to collect the information and then pass to the controllers. Additionally, Inclusive/Selective PMSI Auto Discovery Routes can be originated from controllers based on central provisioning, instead of from PEs based on local provisioning. "Removing Expiration Notices from Internet-Drafts", Martin Thomson, Paul Hoffman, 2024-01-16, The long-standing policy of requiring that Internet-Drafts bear an expiration date is no longer necessary. This document removes requirements for expiration for Internet-Drafts from RFC 2026/BCP 9 and RFC 2418/BCP 25. In place of expiration, this document introduces Internet-Drafts being labeled "active" and "inactive" in the IETF tooling. "Deadline-aware Transport Protocol", Yong Cui, Chuan Ma, Hang Shi, Kai Zheng, Wei Wang, 2024-01-28, This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery. "Braid-HTTP: Synchronization for HTTP", Michael Toomim, Greg Little, Rafie Walker, Bryn Bellomy, Seph Gentle, 2023-11-18, Braid is a set of extensions that generalize HTTP from a state *transfer* protocol into a full state *synchronization* protocol. Braid is composed of four independent extensions to HTTP: "Operational Considerations for BRSKI Registrar", Michael Richardson, Wei Pan, 2024-02-14, 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. "HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2023-12-18, This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System (BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS). Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management. "Security Services for the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2023-12-18, The Industrial Internet Identifier Data Access Protocol (IIIDAP) provides "RESTful" web services to retrieve identifier metadata from Second-Level Node (SLN). This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for IIIDAP. "JSON Responses for the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, 2023-12-18, This document describes JSON data structures representing identifier information maintained by Second-Level Nodes (SLN). These data structures are used to form Industrial Internet Identifier Data Access Protocol (IIIDAP) query responses. "Finding the Authoritative Registration Data (IIIDAP) Service", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2023-12-18, This document specifies a method to find which Industrial Internet Identifier Data Access Protocol (IIIDAP) server is authoritative to answer queries for a request of identifier data. "Industrial Internet Identifier Data Access Protocol (IIIDAP) Query Format", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2023-12-18, This document describes uniform patterns to construct HTTP URLs that may be used to retrieve identifier information from Second-Level Nodes (SLN) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Industrial Internet Identifier Data Access Protocol (IIIDAP). "Resource Allocation Model for Hybrid Switching Networks", Weiqiang Sun, Junyi Shao, Weisheng Hu, 2024-02-14, 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. "OSPF Graceful Restart Enhancements", Sami Boutros, Ankur Dubey, Vijayalaxmi Basavaraj, Acee Lindem, 2023-11-26, This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187. "(strong) AuCPace, an augmented PAKE", Bjoern Haase, 2024-01-19, This document describes AuCPace which is an augmented PAKE protocol for two parties. The protocol was tailored for constrained devices and smooth migration for compatibility with legacy user credential databases. It is designed to be compatible with any group of both prime- and non-prime order and comes with a security proof providing composability guarantees. "Stateless and Scalable Network Slice Identification for SRv6", Clarence Filsfils, Francois Clad, Pablo Camarillo, Syed Raza, Dan Voyer, Reza Rokui, 2024-01-29, This document defines a stateless and scalable solution to achieve network slicing with SRv6. "BGP-LS Extensions for SR Network Resource Partition SIDs", Ran Chen, Shaofu Peng, Tarek Saad, Vishnu Beeram, 2024-01-24, This document specifies extensions to the BGP Link-state address- family in order to advertise the information of Network Resource Partition SIDs. An external component (e.g., a controller) then can collect Network Resource Partition SIDs in the "northbound" direction. The draft is applicable to both SR-MPLS and SRv6 dataplanes. "Scalable Approaches on Supporting IOAM in IPv6", Haoyu Song, Zhenbin Li, Shuping Peng, Jim Guichard, 2024-03-04, 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, and 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. "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Christian Amsuess, 2024-03-18, Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. "Conveying Transceiver-Related Information within RSVP-TE Signaling", Julien Meuric, Esther Le Rouzic, Gabriele Galimberti, 2023-10-23, The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. "No Further Fast Reroute", Kireeti Kompella, Wen Lin, 2023-10-20, There are several cases where, once Fast Reroute has taken place (for MPLS protection), a second fast reroute is undesirable, even detrimental. This memo gives several examples of this, and proposes a mechanism to prevent further fast reroutes. "BGP for Network High Availability", Huaimo Chen, Yanhe Fan, Aijun Wang, Lei Liu, Xufeng Liu, 2023-10-08, This document describes protocol extensions to BGP for improving the reliability or availability of a network controlled by a controller cluster. "PCE for Network High Availability", Huaimo Chen, Aijun Wang, Lei Liu, Xufeng Liu, 2023-10-08, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for improving the reliability or availability of a network controlled by a controller cluster. "IGP for Network High Availability", Huaimo Chen, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu, 2023-10-08, This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. "Using Flex-Algo for Segment Routing (SR) based Network Resource Partition (NRP)", Yongqing Zhu, Jie Dong, Zhibo Hu, 2024-03-03, 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 Flexible Algorithm (Flex-Algo), which can provide constraint-path computation based on the customized topological constraints. This document specifies a mechanism to build Segment Routing (SR) based NRPs by combining SR Flex-Algo and IGP L2 bundles with minor extensions. "Crowd Sourced Remote ID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Shuai Zhao, Henk Birkholz, 2023-10-09, 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 Unmanned 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, 2024-03-16, 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. "Reflexive Forwarding for CCNx and NDN Protocols", David Oran, Dirk Kutscher, 2023-09-26, 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. "Secure UAS Network RID and C2 Transport", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2024-03-16, This document defines a transport mechanism between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. Either the Broadcast Remote ID (B-RID) messages, or alternatively, appropriate MAVLink Messages can be sent directly over UDP or via a more functional protocol using CoAP/CBOR for the Net-RID messaging. This is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure messaging Command-and-Control (C2) for is also described. "LTP Fragmentation", Fred Templin, 2023-10-23, The Licklider Transmission Protocol (LTP) provides a reliable datagram convergence layer for the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol. In common practice, LTP is often configured over UDP/IP sockets and inherits its maximum segment size from the maximum-sized UDP/IP datagram, however when this size exceeds the path maximum transmission unit a service known as IP fragmentation must be engaged. This document discusses LTP interactions with IP fragmentation and mitigations for managing the amount of IP fragmentation employed. "Optimizing ACK mechanism for QUIC", Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang, 2023-11-20, The dependence on frequent acknowledgments (ACKs) is an artifact of current transport protocol designs rather than a fundamental requirement. This document analyzes the problems caused by contentions and collisions on the wireless medium between data packets and ACKs in WLAN and it proposes an ACK mechanism that minimizes the intensity of ACK Frame in QUIC, improving the performance of transport layer connection. "Notable CBOR Tags", Carsten Bormann, 2024-02-10, 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 180 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 a 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. "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2024-03-04, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. "MAC Address for Layer 3 Link Local Discovery Protocol (LLDP)", Donald Eastlake, 2023-12-26, 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. "Recommendations for DNSSEC Resolvers Operators", Daniel Migault, Edward Lewis, Dan York, 2023-11-13, The DNS Security Extensions (DNSSEC) defines a process for validating received data and assert them authentic and complete as opposed to forged. While DNSSEC comes with some complexity, at least for non expert, that complexity is mostly abstracted by the resolver. As result, running a resolver with DNSSEC enabled only requires the operator to only follow a very limited set of recommendations. This document provides such recommendations. "Advertising SID Algorithm Information in BGP", Yao Liu, Shaofu Peng, Gyan Mishra, 2024-03-17, 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. "Identity Module for TLS Version 1.3", Pascal Urien, 2024-01-28, TLS 1.3 will be deployed in the Internet of Things ecosystem. In many IoT frameworks, TLS or DTLS protocols, based on pre-shared key (PSK), are used for device authentication. So PSK tamper resistance, is a critical market request, in order to prevent hijacking issues. If DH exchange is used with certificate bound to DH ephemeral public key, there is also a benefit to protect its signature procedure. The TLS identity module (im) MAY be based on secure element; it realizes some HKDF operations bound to PSK, and cryptographic signature if certificates are used. Secure Element form factor could be standalone chip, or embedded in SoC like eSIM. "Trusted Path Routing", Eric Voit, Chennakesava Gaddam, Guy Fedorkow, Henk Birkholz, Meiling Chen, 2024-02-22, 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, 2023-11-22, 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. "Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection", Tianran Zhou, Giuseppe Fioccola, Gyan Mishra, Hongwei Yang, Chang Liu, 2023-10-23, This document defines optional TLVs which are carried in Simple Two- way Active Measurement Protocol (STAMP) test packets to enhance the STAMP based functions. Such extensions to STAMP enable performance measurement and collection at every node and link along a STAMP test packet's delivery path. It enables Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. "Stateless SRv6 Point-to-Multipoint Path", Huaimo Chen, Mike McBride, Yanhe Fan, Zhenbin Li, Xuesong Geng, Mehmet Toy, Gyan Mishra, Aijun Wang, Lei Liu, Xufeng Liu, 2023-10-22, This document describes a solution for a SRv6 Point-to-Multipoint (P2MP) Path/Tree to deliver the traffic from the ingress of the path to the multiple egresses/leaves of the path in a SR domain. There is no state stored in the core of the network for a SR P2MP path like a SR Point-to-Point (P2P) path in this solution. "BIER Encapsulation for IOAM Data", Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro, 2024-02-01, In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header contains a bit- string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data is encapsulated in BIER header. "Signal Degrade Indication in Segment Routing over MPLS Network", Liuyan Han, Fan Yang, Ren Tan, Junfeng Zhao, 2023-12-27, This document describes a typical use case of MPLS-TP, where signal degrade defect needs to be correctly detected and transmitted via OAM messages within network. When MPLS-TP evolves to Segment Routing MPLS, transit node has no knowledge of labels to be encapsulated in MPLS label stack. Transit node cannot spread OAM messages with signal degrade defect indication. Thus, a solution is proposed in this draft. "SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2024-03-04, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS. "Interconnection Intents", Luis Contreras, Paolo Lucente, 2024-03-04, This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. "Cacheable OSCORE", Christian Amsuess, Marco Tiloca, 2024-01-10, 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. "AS Hijack Detection and Mitigation", Kotikalapudi Sriram, Doug Montgomery, 2024-01-24, This document proposes a method for detection and mitigation of AS hijacking. In this mechanism, an AS operator registers a new object in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is digitally signed using the AS holder's certificate. By registering a REAP object, the AS operator is declaring that they have Route Origin Authorization (ROA) coverage for all prefixes originated by their AS. A receiving AS will mark a route as Invalid if the prefix is not covered by any Validated ROA Payload (VRP) and the route origin AS has signed a REAP. Here Invalid means that the route is determined to be an AS hijack. "IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions", Venkata Munukutla, Shivam Vaid, Aditya Mahale, Devang Patel, 2023-09-19, This draft proposes couple of new Forwarding exceptions related Information Elements (IEs) and Templates for the IP Flow Information Export (IPFIX) protocol. These new Information Elements and Exception Template can be used to export information about any forwarding errors in a network. This essential information is adequate to correlate packet drops to any control plane entity and map it to an impacted service. Once exceptions are correlated to a particular entity, an action can be assigned to mitigate such problems essentially enabling self-driving networks. "SVG Tiny Portable/Secure", Alex Brotman, J. Adams, 2024-03-03, 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. "Secure Element for TLS Version 1.3", Pascal Urien, 2023-10-04, This draft presents ISO7816 interface for TLS1.3 stack running in secure element. It presents supported cipher suites and key exchange modes, and describes embedded software architecture. TLS 1.3 is the de facto security stack for emerging Internet of Things (IoT) devices. Some of them are constraint nodes, with limited computing resources. Furthermore cheap System on Chip (SoC) components usually provide tamper resistant features, so private or pre shared keys are exposed to hacking. According to the technology state of art, some ISO7816 secure elements are able to process TLS 1.3, but with a limited set of cipher suites. There are two benefits for TLS-SE; first fully tamper resistant processing of TLS protocol, which increases the security level insurance; second embedded software component ready for use, which relieves the software of the burden of cryptographic libraries and associated attacks. TLS-SE devices may also embed standalone applications, which are accessed via internet node, using a routing procedure based on SNI extension. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER", Ran Chen, BenChong Xu, Huaimo Chen, Aijun Wang, 2023-10-19, 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, 2023-10-19, 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). "Federated TLS Authentication", Jakob Schlyter, Stefan Halen, 2024-03-18, This document describes the Federated TLS Authentication (FedTLS) protocol, enabling secure end-to-end communication within a federated environment. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedTLS 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. "MSYNC", Sophie Bale, Remy Brebion, Guillaume Bichot, 2023-12-22, 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, 2024-02-17, 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). "Revised Cookie Processing in the IKEv2 Protocol", Valery Smyslov, 2023-10-16, This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. "Network measurement intent - one of IBN use cases", Danyang Chen, Hongwei Yang, Kehan Yao, Giuseppe Fioccola, Qin WU, Luis Contreras, 2023-10-22, As an important technical mean to detect network state, network measurement has attracted more and more attention in the development of networks. However, the current network measurement technology has the problem that the measurement method and the measurement purpose are not well matched. To solve this problem, this memo introduces network measurement intent, presents a process of scheduling the network resources and measurement tasks to meet the user or network operator's needs. And it can be seen as a specific use case of intent based network. "BIER Egress Protection", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Michael Menth, Boris Khasanov, Xuesong Geng, Yanhe Fan, Lei Liu, Xufeng Liu, 2023-12-26, This document describes a mechanism for fast protection against the failure of an egress node of a "Bit Index Explicit Replication" (BIER) domain. It is called BIER egress protection. It does not require any per-flow state in the core of the domain. With BIER egress protection the failure of a primary BFER (Bit Forwarding Egress Router) is protected with a backup BFER such that traffic destined to the primary BFER in the BIER domain is fast rerouted by a neighbor BFR to the backup BFER on the BIER layer. The mechanism is applicable if all BIER traffic sent to the primary BFER can reach its destination also via the backup BFER. It is complementary to BIER- FRR which cannot protect against the failure of a BFER. "Security Management Automation of Cloud-Based Security Services in I2NSF Framework", Jaehoon Jeong, Patrick Lingga, J., PARK, Diego Lopez, Susan Hares, 2024-02-07, This document describes Security Management Automation (SMA) of cloud-based security services in the framework of Interface to Network Security Functions (I2NSF). The security management automation in this document deals with closed-loop security control, security policy translation, and security audit. To support these three features in SMA, this document specifies an augmented architecture of the I2NSF framework with new system components and new interfaces. "SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li, 2024-02-19, 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. "SRv6 In-situ Active Measurement", Haoyu Song, Gyan Mishra, Tian Pan, 2024-03-04, This draft describes an active measurement method for SRv6 which can support segment-by-segment and end-to-end measurement on any SRv6 path using existing protocols such as IOAM. A packet containing an SRH uses a flag bit to indicate the packet is an active probing packet and requires segment-by-segment processing. The measurement information, such as the IOAM header and data, is encapsulated in UDP payload, indicated by a dedicated port number. The probing packet originates from a segment source node, traverses an arbitrary segment path, and terminates at a segment endpoint node, as configured by the segment list in SRH. Each segment node on the path, when detecting the flag, shall parse the UDP header and the payload. In the case of IOAM, the node shall process the IOAM option conforming to the standard procedures defined in the IOAM documents. The method is compatible with some other SRv6 active measurement proposals and support multiple applications. "SR-MPLS / SRv6 Transport Interworking", Shraddha Hegde, Parag Kaneriya, Ron Bonica, Shaofu Peng, Greg Mirsky, Zheng Zhang, Bruno Decraene, Dan Voyer, Swadesh Agrawal, 2024-01-01, This document describes procedures for interworking between an SR- MPLS transit domain and an SRv6 transit domain. Each domain contains Provider Edge (PE) and Provider (P) routers. Area Border Routers (ABR) provide connectivity between domains. The procedures described in this document require the ABR to carry a route to each PE router. However, they do not required the ABR to carry service (i.e., customer) routes. In that respect, these procedures resemble L3VPN Interprovider Option C. Procedures described in this document support interworking for global IPv4 and IPv6 service prefixes. They do not support interworking for VPN services prefixes where the SR-MPLS domain uses MPLS service labels. "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, 2024-01-29, This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". "Application of the Alternate Marking Method to the Segment Routing Header", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang, 2024-02-08, 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 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. This protocol extension has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale deployment to determine the potential benefits of this approach. "BGP Extensions of SR Policy for Composite Candidate Path", Hao Li, Mengxiao Chen, Changwang Lin, Jiang Wenying, Weiqiang Cheng, 2024-02-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. "Signaling Composite Candidate Path of SR Policy using BGP-LS", Hao Li, Mengxiao Chen, Changwang Lin, Jiang Wenying, Weiqiang Cheng, 2024-02-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, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. "PCEP Extensions for sid verification for SR-MPLS", Ran Chen, Samuel Sidor, Chun Zhu, Alex Tokar, Mike Koldychev, 2024-02-21, This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. "Simple Two-Way Direct Loss Measurement Procedure", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, 2024-02-04, This document defines Simple Two-Way Direct Loss Measurement (DLM) procedure that can be used for Alternate-Marking Method for detecting accurate data packet loss in a network. Specifically, DLM probe packets are defined for both unauthenticated and authenticated modes and they are efficient for hardware-based implementation. "BIER-TE Fast ReRoute", Huaimo Chen, Mike McBride, Yisong Liu, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2024-01-31, This document describes a mechanism for fast re-route (FRR) protection against the failure of a transit node or link on an explicit point to multipoint (P2MP) multicast path/tree in a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. It does not have any per-path state in the core. For a multicast packet to traverse a transit node along an explicit P2MP path, when the node fails, its upstream hop node as a PLR reroutes the packet around the failed node along the P2MP path once it detects the failure. "BIER-TE Egress Protection", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2023-12-26, This document describes a mechanism for fast protection against the failure of an egress node of an explicit point to multipoint (P2MP) multicast path/tree in a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. It does not have any per-flow state in the core of the domain. For a multicast packet to the egress node, when the egress node fails, its upstream hop as a PLR sends the packet to the egress' backup node once the PLR detects the failure. "NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol", Martin Langer, Rainer Bermbach, 2024-02-16, 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 relevant PTP modes and operates completely independent of NTPv4. "RPKI Validation Re-reconsidered", Job Snijders, Ben Maddison, 2023-11-07, This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6482. This document updates RFC 6487. This document obsoletes RFC 8360. "Applicability of IETF-Defined Service and Network Data Models for RFC XXXX Network Slice Service Management", Samier Barguil, Luis Contreras, Victor Lopez, Oscar de Dios, Mohamed Boucadair, Reza Rokui, 2023-10-23, This document exemplifies how the various data modeles that are produced in the IETF can be combined in the context of RFC XXXX Network Slice Services delivery. Specifically, this document describes the relationship between the RFC XXXX Network Slice Service models for requesting Network Slice Services and both Service (e.g., the Layer-3 Service Model, the Layer-2 Service Model) and Network (e.g., the Layer-3 Network Model, the Layer-2 Network Model) models used during their realizations. In addition, this document describes the communication between an RFC XXXX Network Slice Controller (NSC) and the network controllers for the realization of RFC XXXX Network Slices. The RFC XXXX 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 the RFC XXXX Network Slice requirements, and the gaps in existing models are identified. Note to the RFC Editor: Please replace "RFC XXXX" with the RFC number assigned to I-D.ietf-teas-ietf-network-slices. "Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation", Carsten Bormann, 2023-10-23, The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. 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 format and a compact format (Annex C), this specification defines a compact format to go along SDF's JSON 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. "The Time Zone Information Format (TZif)", Arthur Olson, Paul Eggert, Kenneth Murchison, 2024-03-16, This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. "Scalable Remote Attestation for Systems, Containers, and Applications", Kathleen Moriarty, Antonio Fontes, 2023-10-23, 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, preventing 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). "Prague Congestion Control", Koen De Schepper, Olivier Tilmans, Bob Briscoe, Vidhi Goel, 2023-10-14, This specification defines the Prague congestion control scheme, which is derived from DCTCP and adapted for Internet traffic by implementing the Prague L4S requirements. Over paths with L4S support at the bottleneck, it adapts the DCTCP mechanisms to achieve consistently low latency and full throughput. It is defined independently of any particular transport protocol or operating system, but notes are added that highlight issues specific to certain transports and OSs. It is mainly based on experience with the reference Linux implementation of TCP Prague and the Apple implementation over QUIC, but it includes experience from other implementations where available. The implementation does not satisfy all the Prague requirements (yet) and the IETF might decide that certain requirements need to be relaxed as an outcome of the process of trying to satisfy them all. Future plans that have typically only been implemented as proof-of- concept code are outlined in a separate section. "Security Technical Specification for Smart Devices of IoT", Bin Wang, Xing Wang, Li Wan, Wenyuan Xu, Chonghua Wang, HaoNan Yan, Yinghui Xie, 2023-10-18, With the development of IoT, the security of smart devices has become an important issue for us to discuss. This draft proposes a security framework and detailed requirements in terms of hardware, system, data, network, and management to ensure the security of IoT smart devices. Specifically, hardware security includes the security of hardware interfaces and components. System security encompasses firmware security, security audits, and more. Data security involves data verification and protection of sensitive data.Network security entails stream protection, session security, and more. "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, 2023-10-18, It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. "Open Service Access Protocol for IoT Smart Devices", Bin Wang, Shaopeng Zhou, Chao Li, Chunming Wu, Zizhao Wang, HaoNan Yan, Yinghui Xie, 2023-10-18, With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. "Fetch and Validation of Verified Mark Certificates", Wei Chuang, Marc Bradshaw, Thede Loder, Alex Brotman, 2024-03-03, 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, 2024-03-03, 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. "Common Format and MIME Type for Comma-Separated Values (CSV) Files", Yakov Shafranovich, 2024-01-31, This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". "Data Transmission Security of Identity Resolution in Industrial Internet", Bin Wang, Kezhang Lin, Chonghua Wang, Xing Wang, HaoNan Yan, Yinghui Xie, 2023-10-18, This draft presents a comprehensive overview of the data transmission security within the identity resolution system for the Industrial Internet. Identity resolution systems play a vital role in the Industrial Internet, facilitating secure sharing and intelligent correlation of heterogeneous information across various organizations. This draft focuses on the security services that identity resolution systems should provide during the resolution process. "Retrieving information about Object Identifiers using a text-based protocol", Daniel Marschall, 2024-01-23, This document defines a method for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) through a text-based protocol, in a way that is both human-readable and machine-readable. Besides a text output format, OID-IP also supports sending information in JSON and XML. "Using NETCONF over QUIC connection", Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Huaimo Chen, Xueshun Wang, Yang Kou, Lifen Zhou, 2024-01-05, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. At present, almost all implementations of NETCONF are based on TCP based protocol. QUIC, a new UDP-based, secure and multiplexed transport protocol, can facilitate to improve the transportation performance, information security and resource utility when being used as an infrastructure layer of NETCONF. This document describes how to use the QUIC protocol as the transport protocol of NETCONF(It is so called NETCONFoQUIC). "Internet of Secure Elements", Pascal Urien, 2024-02-25, This draft defines an infrastructure for secure elements over internet, and features needed for their secure remote use. It describes a network architecture based on the TLS 1.3 protocol, which enables remote calls of cryptographic procedures, identified by Unified Resource Identifier (URI) such as schemeS://sen@server.com:443/?query The Internet of Secure Element (IoSE) is a set of secure elements providing TLS servers, communication interfaces, and identified by their name (Secure Element Name, sen). "PCEP Procedures and Extension for VLAN-based Traffic Forwarding", Yue Wang, Aijun Wang, Boris Khasanov, Fengwei Qin, Huaimo Chen, Chun Zhu, 2024-03-01, This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. "HESP - High Efficiency Streaming Protocol", Pieter-Jan Speelmans, 2023-10-16, This document describes a protocol for delivering multimedia data, enabling ultra-low latency and fast channel change over HTTP networks. 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 2 of this protocol. "BGP Flow Specification for DetNet and TSN Flow Mapping", Quan Xiong, Haisheng Wu, Junfeng Zhao, Dong Yang, 2023-10-16, This document proposes extensions to BGP Flow Specification for the flow mapping of Deterministic Networking (DetNet) when interconnected with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is used for the filtering of the packets that match the DetNet newtworks and the mapping between TSN streams and DetNet flows in the control plane. "Problem Statement and Use Cases of Trustworthiness-based Routing", Tao Lin, Hao Li, Xingang Shi, Xia Yin, Wenlong Chen, Mengxiao Chen, 2024-01-23, Currently, network operators are trying to provide fine-granularity Service Level Agreement (SLA) guarantee to achieve better Quality of Experience (QoE) for end users and engage customers, such as ultra- low latency and high reliability service. However, with increasing security threats, differentiated QoE services are insufficient, the demands for more differentiated security service are emerging. This document explores the requirements for differentiated security services and identifies the scenarios for network operators. To provide differentiated security services, possible trustworthiness- based routing solution is discussed. "SRv6-based BGP Service Capability", Yao Liu, Zheng Zhang, Eduard Metz, Yisong Liu, 2024-02-22, This draft describes the problems that may be encountered during the deployment of SRv6-based BGP services in the co-existence scenario where the network supports both SRv6 and MPLS in a given domain, and the possible solutions. "Separation Protocol of Locator and Identifier Towards IPv6", haisheng yu, Hanzhuo Zhang, 2023-10-09, In the current TCP/IP architecture, the IPv6 address has a dual meaning in semantics. It not only represents the topological location of the network node, but also the identity of the node, which is usually referred to as the semantic overload problem of the IP address. The semantically overloaded IP address represents the topological position of the network, and the topological position of the network generally does not move, so the device entering the new network environment needs to replace the new identity IP to adapt to the change of the topological position. The semantic overload of IP addresses is not conducive to supporting mobility and user identity authentication, resulting in tight storage space for routing equipment, lack of unified communication identification for network equipment, and difficulties in network traceability and management. In order to solve the problem of IP address semantic overload, this draft focuses on the separation technology SPLIT6 (Separation Protocol of Locator and Identifier Towards IPv6) of IP address identity and location. "Problems and Requirements of Satellite Constellation for Internet", Lin Han, Richard LI, Alvaro Retana, Meiling Chen, Li Su, Tianji Jiang, 2024-01-04, This document presents the detailed analysis about the problems and requirements of satellite constellation used for Internet. It starts from the satellite orbit basics, coverage calculation, then it estimates the time constraints for the communications between satellite and ground-station, also between satellites. How to use satellite constellation for Internet is discussed in detail including the satellite relay and satellite networking. The problems and requirements of using traditional network technology for satellite network integrating with Internet are finally outlined. "Generic Metric for the AIGP attribute", Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, Bin Wen, Marcin Kozak, Jie Dong, Luay Jalil, Ketan Talaulikar, 2023-11-09, This document defines extensions to the AIGP attribute to carry Generic Metric sub-types. This is applicable when multiple domains exchange BGP routing information. The extension will aid in intent- based end-to-end path selection. "Find Code Related to an Internet-Draft or RFC", Charles Eckel, 2024-01-22, Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and find such code. "SRv6 inter-domain mapping SIDs", Rajesh Shetty, Ron Bonica, Haibo Wang, Shaofu Peng, 2024-03-18, This document describes three new SRv6 end-point behaviors, called END.REPLACE, END.REPLACEB6 and END.DB6. These behaviors are used in distributed inter-domain solutions and are normally executed on border routers. They also can be used to provide multiple intent- based paths across these domains. "Security for the NFSv4 Protocols", David Noveck, 2024-03-03, 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 ACL feature, 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, "PCE for BIER-TE Ingress Protection", Huaimo Chen, Mike McBride, Gyan Mishra, Yisong Liu, Aijun Wang, Lei Liu, Xufeng Liu, 2023-11-12, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for protecting the ingress of a BIER-TE path. "EVPN multi-homing support for L3 services", Michael MacKenzie, Patrice Brissette, Satoru Matsushima, Wen Lin, Jorge Rabadan, 2024-02-07, 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, 2024-01-07, This document describes a method to encode network slicing identifier within SRv6 domain. "YANG Data Model for Topology Filter", Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, 2024-02-20, This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. "Service Function Chaining (SFC) Parallelism and Diversions", Donald Eastlake, 2023-11-26, 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. "Encapsulation of Simple TWAMP (STAMP) for Pseudowires and LSPs in MPLS Networks", Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min, 2024-02-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. "Security and Privacy Considerations for Multicast Transports", Kyle Rose, Jake Holland, 2023-12-27, 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. "Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet, Michael Behringer, 2024-01-05, This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. "Transient Hiding of Hop-by-Hop Options", Donald Eastlake, Jie Dong, 2023-12-31, 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. "MPLS Network Action for Transporting In Situ OAM Data Fields", Rakesh Gandhi, Frank Brockners, Bin Wen, Bruno Decraene, Haoyu Song, 2024-03-17, In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document defines MPLS Network Action for transporting IOAM data fields. "Advertisement of Stub Link Attributes", Aijun Wang, Zhibo Hu, Gyan Mishra, Jinsong Sun, 2023-11-24, This document describes the mechanism that can be used to advertise the stub link attributes within the IS-IS or OSPF domain. "MTU propagation over EVPN Overlays", DIKSHIT Saumya, Vinayak Joshi, A Nayak, 2024-01-28, 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. "Knowledge Transmission Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel", Kun Li, Hua-chun Zhou, Zhe Tu, Feiyang Liu, Weilin Wang, 2024-02-20, The document specifies new DOTS data channel configuration parameters that customize the DDoS knowledge transmission configuration between distributed knowledge bases. These options enable assist the distributed knowledge base to share attack knowledge in different fields and actively adapt to dynamically changing DDoS attacks. "BGP-LS extensions for BIER-TE", Ran Chen, Zheng Zhang, Yisong Liu, Changwang Lin, 2023-10-19, 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. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path 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 BIER-TE informations. "Defreezing Optimization post EVPN Mac Dampening", DIKSHIT Saumya, Vinayak Joshi, Swathi Shankar, 2024-01-28, 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. "Antitrust Guidelines for IETF Participants", Joel Halpern, Jay Daley, 2024-02-29, This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. "All PEs as DF", DIKSHIT Saumya, Vinayak Joshi, 2024-01-28, 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. "Algorithm Related Adjacency SID Advertisement", Ran Chen, Shaofu Peng, Peter Psenak, Yao Liu, 2023-09-22, This draft describes a mechanism to distribute SR-MPLS algorithm Related Adjacency SID from controllers to the headend routers using BGP-LS. "Updates to Anycast Property advertisement for OSPFv2", Ran Chen, Detao Zhao, Peter Psenak, Ketan Talaulikar, Changwang Lin, 2024-02-23, 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. "Extending ICMP for IP-related Information Validation", Yao Liu, Yisong Liu, 2023-10-23, This document introduces the mechanism to verify the data plane against the control plane in IPv6/SRv6 networks by extending ICMPv6 messages. "Secure Vector Routing (SVR)", Abilash Menon, Patrick MeLampy, Michael Baj, Patrick Timmons, Hadriel Kaplan, 2024-03-18, This document describes Secure Vector Routing (SVR). SVR is an overlay inter-networking protocol that operates at the session layer. SVR provides end-to-end communication of network requirements not possible or practical using network header layers. SVR uses application layer cookies that eliminate the need to create and maintain non-overlapping address spaces necessary to manage network routing requirements. SVR is an overlay networking protocol that works through middleboxes and address translators including those existing between private networks, the IPv4 public internet, and the IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases and improves security at the networking routing plane. SVR eliminates the need for encapsulation and decapsulation often used to create non-overlapping address spaces. "Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level", Murray Kucherawy, 2022-10-20, IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document defines the procedure used in these circumstances. This document merges and updates, and thus obsoletes, RFC 3967, RFC 4897, and RFC 8067. "Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, Alex Brotman, 2024-03-03, 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, 2024-02-20, 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. "Scalability of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse, 2023-10-14, Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the scalability of the five most prominent IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T) considering two aspects: (1) how their performance scales up with the number of CPU cores, (2) how their performance degrades, when the number of concurrent sessions is increased until hardware limit is reached. "Updated Rules for PCE Communication Protocol (PCEP) Object Ordering", Dhruv Dhody, 2023-12-31, 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 message 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, 2023-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. "Artificial Intelligence Framework for Network Management", Pedro Martinez-Julia, Shunsuke Homma, Diego Lopez, 2023-10-21, The adoption of artificial intelligence (AI) in network management (NM) solutions is the way to resolve many of the complex management problems arising from the adoption of NFV and SDN technologies. The AINEMA framework, as discussed in this document, includes the functions, capabilities, and components that MUST be provided by AI modules and models to be successfully applied to NM. This is enhanced by the consideration of seamless integration of different services, including the ability of having multiple AI models working in parallel, as well as the ability of complex reasoning and event processing. In addition, disparate sources of information are put together without increasing complexity, through the definition of a control and management service bus. It allows, for instance, to involve external events in NM operations. Using all available sources of information --- namely, intelligence sources --- allows NM solutions to apply proper intelligence processes that provide explainable results instead of simple AI-based guesses. Such processes are highly based in reasoning and formal and target-based intelligence analysis and decision --- providing evidence-based conclusions and proofs for the decisions --- in the form of AI method outputs with explanations. This will allow computer and network system infrastructures --- and user demands --- to grow in complexity while keeping dependability. "Unicast Use of the Lowest Address in an IPv4 Subnet", Seth Schoen, John Gilmore, David Taht, Michael Karels, 2023-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. "BIER-TE for Broadcast Link", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Lei Liu, Xufeng Liu, 2023-10-18, This document describes extensions to "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) for supporting LANs (i.e., broadcast links). For a multicast packet with an explicit point-to-multipoint (P2MP) path traversing LANs, the packet is replicated and forwarded statelessly along the path. "BGP-SPF Flooding Reduction", Huaimo Chen, Gyan Mishra, Aijun Wang, Yisong Liu, Haibo Wang, Yanhe Fan, 2023-12-26, This document describes extensions to Border Gateway Protocol (BGP) for flooding the link states on a topology that is a subgraph of the complete topology of a BGP-SPF domain, so that the amount of flooding traffic in the domain is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. "Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option", Ted Lemon, Liang Qin, 2024-03-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. "BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches", Fanghong Duan, Jingrong Xie, Siyu Chen, 2023-11-21, MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. "Multicast VPN Upstream Designated Forwarder Selection", Fanghong Duan, Siyu Chen, Yisong Liu, Heng Wang, 2023-11-21, This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. "Traffic Mapping YANG model for Traffic Engineering (TE)", Dhruv Dhody, 2024-03-04, This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model providers operator a seamless control and management of which traffic to send on the underlying TE resources. "IETF Network Slice Deployment Status and Considerations", Yusong Ma, Rui Luo, Alex Chan, Ben Suen, Jie Dong, Yang Liu, Houcine Allahoum, 2023-10-23, Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided. "RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6", Yisong Liu, Jingrong Xie, Xuesong Geng, Mengxiao Chen, 2023-10-23, This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. "Flow Measurement in IPv6 Network", Haojie Wang, Yisong Liu, Changwang Lin, Xiao Min, Greg Mirsky, 2024-01-09, This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. "Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks", Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin, Bin Wen, 2023-10-23, 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. "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", Alexey Melnikov, 2024-03-04, This document updates requirements on implementations of various Salted Challenge Response Authentication Mechanism (SCRAM) Simple Authentication and Security Layer (SASL) mechanisms based on more modern security practices. "EVPN Fast Reroute", Luc Burdet, Patrice Brissette, Takuya Miyasaka, Jorge Rabadan, 2024-03-04, This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. "TCPLS: Modern Transport Services with TCP and TLS", Maxime Piraux, Florentin Rochet, Olivier Bonaventure, 2023-10-23, This document specifies a protocol leveraging TCP and TLS to provide modern transport services such as multiplexing, connection migration and multipath in a secure manner. 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/mpiraux/draft-piraux-tcpls. "BGP SR Policy Extensions for template", KaZhang, Zhibo Hu, Jie Dong, 2023-09-24, 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. "Semantic Definition Format (SDF): Mapping files", Carsten Bormann, Jan Romann, 2023-12-03, 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. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation. "TLS for Secure Element Input Output (TLS-SE-IO)", Pascal Urien, 2024-02-25, The goal of TLS-SE-IO is to provide virtual IO pins for secure elements running TLS servers, in order to interact with sensors and actuators. TLS-SE device processes TLS packets in secure element. It may work like a black box (server mode) that exchanges fully encrypted packets. It may also export encrypted packet in clear form, in order to provide virtual output pin. Output messages may include cookies and/or cryptographic materials. Virtual input pin forwards input messages, triggered by previous output messages, and sent to TLS-SE device for further processing. "Unicast Use of the Formerly Reserved 0/8", Seth Schoen, John Gilmore, David Taht, 2023-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-02-28, 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. "Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements", Thomas Fossati, Yogesh Deshpande, Henk Birkholz, 2024-03-04, PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. "Control Plane of Inter-Domain Source Address Validation Architecture", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2023-11-21, Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. "Data Plane of Inter-Domain Source Address Validation Architecture", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2023-11-21, Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added 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 Inter-Domain Source Address Validation Architecture", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2023-11-21, Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. "Open Ethics Transparency Protocol", Nikita Lukianets, 2023-11-15, 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 Format is an extensible JSON-based format. "IPlir network layer security protocol", Davletshina Alexandra, Urivskiy Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia, 2023-09-29, 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. "RIFT Auto-Flood Reflection", Jordan Head, Tony Przygienda, Colby Barth, 2024-02-29, This document specifies procedures where RIFT can automatically provision IS-IS Flood Reflection topologies by leveraging its native no-touch ZTP architecture. "Deprecation Of The IPv6 Router Alert Option", Ron Bonica, 2024-02-19, 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, protocols standardized in the future must not use the Router Alert Option. "A Label/SID Allocation Method for VPN Interworking Option B", Yao Liu, Shaofu Peng, 2023-09-19, This document analyzes the SRv6-MPLS service interworking option B solution and proposes an MPLS label/SRv6 SID allocation method for label/SID saving and better scalability purpose. "Deadline Based Deterministic Forwarding", Shaofu Peng, Zongpeng Du, Kashinath Basu, czp@h3c.com, Dong Yang, Chang Liu, 2024-03-01, This document describes a deterministic forwarding mechanism to IP/ MPLS network, as well as corresponding resource reservation, admission control, policing, etc, to provide guaranteed latency. Especially, latency compensation with core stateless is discussed to replace reshaping to be suitable for Diff-Serv architecture [RFC2475]. "RLB (Replication through Local Bitstring) Segment for Multicast Source Routing over IPv6", Xuesong Geng, Zhenbin Li, Jingrong Xie, 2023-10-23, This document defines 2 new types of segment: End.RLB.X and End.RLB, and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions. "Impact of DLTs on Provider Networks", Dirk Trossen, David Guzman, Mike McBride, Xinxin Fan, 2024-02-09, This document discusses the impact of distributed ledger technologies being realized over IP-based provider networks. The focus here lies on the impact that the DLT communication patterns have on efficiency of resource usage in the underlying networks. We provide initial insights into experimental results to quantify this impact in terms of inefficient and wasted communication, aligned along challenges that the DLT realization over IP networks faces. This document intends to outline this impact but also opportunities for network innovations to improve on the identified impact as well as the overall service quality. While this document does not promote specific solutions that capture those opportunities, it invites the wider community working on DLT and network solutions alike to contribute to the insights in this document to aid future research and development into possible solution concepts and technologies. The findings presented here have first been reported within the similarly titled whitepaper released by the Industry IoT Consortium (IIC) [IIC_whitepaper]. "Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth", Xiao Min, Zheng Zhang, Weiqiang Cheng, 2024-01-28, Flow-ID Label (FL) is used for MPLS flow identification and flow- based performance measurement with alternate marking method. The ability to process Flow-ID labels is called Flow-ID Label Capability (FLC), and the capability of reading the maximum label stack depth and performing FL-based performance measurement is called Flow-ID Readable Label Depth (FRLD). This document defines a mechanism to signal the FLC and the FRLD using IGP and BGP-LS. "PCEP Extension for Bounded Latency", Quan Xiong, Peng Liu, Rakesh Gandhi, 2024-02-28, In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. "IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension", Daiying Liu, Daniel Migault, Renwang Liu, Congjie Zhang, 2023-10-06, 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, 2023-12-24, 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. "Enhanced DetNet Data Plane Framework for Scaling Deterministic Networks", Quan Xiong, Zongpeng Du, Junfeng Zhao, Dong Yang, 2024-02-26, The Enhanced Deterministic Networking (EDN) is required to provide the enhancement of flow identification and packet treatment for Deterministic Networking (DetNet) to achieve the DetNet QoS in scaling networks. This document proposes the enhancement of the framework to support the functions and metadata for enhanced DetNet data plane. "Extensible Provisioning Protocol (EPP) Transport over HTTP", Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould, 2024-02-20, This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a Hypertext Transfer Protocol (HTTP) connection. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). "Everything over CoAP", Christian Amsuess, 2024-03-04, The Constrained Application Protocol (CoAP) has become the base of applications both inside of the constrained devices space it originally aimed for and outside. This document gives an overview of applications that are, can, may, and would better not be implemented on top of CoAP. "SRPM Path Consistency over SRv6", sijun weng, Weiqiang Cheng, Changwang Lin, Xiao Min, 2023-11-08, 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. "Advertisement of Dedicated Metric for Flexible Algorithm in IGP", Changwang Lin, Mengxiao Chen, Weiqiang Cheng, Liyan Gong, 2024-03-03, This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. "BGP SPF for Network Resource Partitions", Jie Dong, Zhenbin Li, Haibo Wang, Jian Ge, 2023-10-20, A VTN is a virtual underlay network which has customized network topology and a set of dedicated or shared network resources. Network Resource Partition (NRP) refers to a set of network resources that are available to carry traffic and meet the SLOs and SLEs. Multiple NRPs can be created in a network to provide different Virtual Transport Networks (VTN) to meet the requirements of different services or different service groups. As the number of NRP increases, there can be scalability concerns about using Interial Gateway Protocols (IGP) to distribute the NRP information in the network. In networks where BGP Shortest Path First (SPF) can used as the underlay routing mechanism to distribute the link-state information among network nodes, the information of NRPs needs to be distributed along with the basic network information. This document specifies the BGP SPF mechanisms with necessary extensions to distribute the NRP information and perform NRP-specific path computation. "Stateless Traffic Engineering Multicast using MRH", Huaimo Chen, Mike McBride, Yanhe Fan, Zhenbin Li, Xuesong Geng, Mehmet Toy, Gyan Mishra, Yisong Liu, Aijun Wang, Lei Liu, Xufeng Liu, 2024-01-10, This document describes a stateless traffic engineering (TE) multicast along an explicit P2MP Path/Tree using an IPv6 extension header called TE multicast routing header (MRH). The MRH with the path encoded in link numbers is added into a packet to be multicast at the ingress. The packet is delivered to the egresses along the path. There is no state stored in the core of the network. "Signalling CC Parameters for Careful Resume using QUIC", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Raffaello Secchi, Christian Huitema, 2024-03-04, This document describes an extension for QUIC. This enables the exchange of Congestion Control (CC) parameters related to the characteristics of the between the sender and the receiver during a connection. These CC parameters allow a receiver to prepare to use additional capacity that is made available when using Careful Resume. It can also allow a receiver to request that previously computed CC parameters, are not used when the receiver has additional information about the current path or traffic that is to be sent. "The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record", Donald Eastlake, Haoyu Song, 2023-09-29, A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. "Mobile User Plane Evolution", Zhaohui Zhang, Keyur Patel, Luis Contreras, Kashif Islam, Jari Mutikainen, Tianji Jiang, Luay Jalil, Ori Sejati, Shay Zadok, 2024-02-23, This document describes evolution of mobile user plane in 5G, including distributed User Plane Functions (UPFs) and alternative user plane implementations that some vendors/operators are promoting without changing 3GPP architecture/signaling, and further discusses potentially integrating UPF and Access Node (AN) in 6G mobile networks. This document is not an attempt to do 3GPP work in IETF. Rather, it discusses potential integration of IETF/wireline and 3GPP/wireless technologies - first among parties who are familiar with both areas and friendly with IETF/wireline technologies. If the ideas in this document are deemed reasonable, feasible and desired among these parties, they can then be brought to 3GPP for further discussions. "Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks", Sheng Liu, Haomian Zheng, Aihua Guo, Yang Zhao, Daniel King, 2023-10-11, 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. "Considerations of deploying AI services in a distributed method", Yong-Geun Hong, Oh Seokbeom, Joo-Sang Youn, SooJeong Lee, Seung-Woo Hong, Ho-Sun Yoon, 2023-10-23, As the development of AI technology matured and AI technology began to be applied in various fields, AI technology is changed from running only on very high-performance servers with small hardware, including microcontrollers, low-performance CPUs and AI chipsets. In this document, we consider how to configure the network and the system in terms of AI inference service to provide AI service in a distributed method. Also, we describe the points to be considered 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 AI services in a distributed method such as self-driving car and digital twin network are described. "Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries", Donald Eastlake, Haoyu Song, 2023-09-29, 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). "Encrypted Client Hello Deployment Considerations", Andrew Campling, Paul Vixie, David Wright, Arnaud Taddei, Simon Edwards, 2024-01-24, (Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. "Ethernet VPN Virtual Private Wire Services Gateway Solution", Jorge Rabadan, Senthil Sathappan, Vinod Prabhu, Wen Lin, Patrice Brissette, 2024-01-31, 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. "BGP Extensions for the Mobile User Plane (MUP) SAFI", Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer, 2023-11-05, 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. "A YANG Data Model for Open Shortest Path First (OSPF) Topology", Oscar de Dios, Samier Barguil, Victor Lopez, 2023-10-23, This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "A YANG Data Model for SRv6 Mobile User Plane", Mahesh Jethanandani, Tetsuya Murakami, Kalyani Rajaraman, Satoru Matsushima, 2023-10-16, This document defines a YANG data model for configuration and management of Mobile User Plane (MUP) in a SRv6 network. "The Architecture of Network-Aware Domain Name System (DNS)", Haoyu Song, Donald Eastlake, 2024-03-04, 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. "Tracing process in IPv6 VPN Tunneling Networks", Shuping Peng, Yisong Liu, zhaoranxiao, Pingan Yang, 2024-01-27, This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. "TCP RST Diagnostic Payload", Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-02-26, 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, 2024-02-04, 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, 2024-01-30, This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] 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. "SM2 Digital Signature Algorithm for DNSSEC", Cuiling Zhang, Yukun Liu, Feng Leng, Qi Zhao, Zheng He, 2024-01-18, This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC). This draft is an independent submission to the RFC series, and does not have consensus of the IETF community. "IS-IS Extension to Advertise SRv6 SIDs using SID Block", Weiqiang Cheng, Jiang Wenying, Changwang Lin, Mengxiao Chen, Liyan Gong, Yao Liu, 2024-01-16, This document proposes a simplified method to advertise SRv6 SIDs in IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs within the address range of a Locator. When a SID is assigned from the SID Block, it is described by an index based on the SID Block, instead of the whole 128-bit IPv6 address. "Advertising Exclusive Links for Flex-Algorithm in IGP", Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Ran Chen, Yanrong Liang, 2024-03-03, This document proposes the method to advertise exclusive links for Flex-Algorithm in IGP. "IPv6 Option for DetNet Data Fields", Quan Xiong, Junfeng Zhao, Rakesh Gandhi, 2023-10-12, The DetNet data fields defined in Deterministic Latency Action (DLA) can be used in enhanced Deterministic Networking (DetNet) to provide QoS treatment to achieve deterministic latency. This document defines how DetNet data fields are encapsulated in IPv6 option. "SR Policies Extensions for NRP in BGP-LS", Ran Chen, Jie Dong, Detao Zhao, Liyan Gong, Yongqing Zhu, Ran Pang, 2024-03-17, This document defines a new TLV which enable the headend to report the configuration and the states of SR policies carrying NRP information by using BGP-LS. "SRv6 Egress Protection in Multi-homed scenario", Weiqiang Cheng, Jiang Wenying, Changwang Lin, Zhibo Hu, Yuanxiang Qiu, 2023-09-17, This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. "Epoch Markers", Henk Birkholz, Thomas Fossati, Wei Pan, Carsten Bormann, 2023-10-23, This document defines Epoch Markers as a way 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, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. "BGP Blockchain", Mike McBride, Dirk Trossen, David Guzman, Thomas Martin, 2024-02-06, A variety of mechanisms have been developed and deployed over the years to secure BGP including the more recent RPKI/ROA mechanisms. Is it also possible to use a distributed ledger such as Blockchain to secure BGP? BGP provides decentralized connectivity across the Internet. Blockchain provides decentralized secure transactions in a append-only, tamper-resistant ledger. This document reviews possible opportunities of using Blockchain to secure BGP policies within a domain and across the global Internet. We propose that BGP data could be placed in a blockchain and smart contracts can control how the data is managed. This could create a single source of truth, something for which blockchains are particularly well suited. "Multicast Extension for QUIC", Jake Holland, Lucas Pardue, Max Franke, 2024-01-09, 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. "SCION Overview", Corine de Kater, Nicola Rustignoli, Adrian Perrig, 2023-11-05, The Internet has been successful beyond even the most optimistic expectations and is intertwined with many aspects of our society. But although the world-wide communication system guarantees global reachability, the Internet has not primarily been built with security and high availability in mind. The next-generation inter-network architecture SCION (Scalability, Control, and Isolation On Next- generation networks) aims to address these issues. SCION was explicitly designed from the outset to offer security and availability by default. The architecture provides route control, failure isolation, and trust information for end-to-end communication. It also enables multi-path routing between hosts. This document discusses the motivations behind the SCION architecture and gives a high-level overview of its fundamental components, including its authentication model and the setup of the control- and data plane. As SCION is already in production use today, the document concludes with an overview of SCION deployments. For detailed descriptions of SCION's components, refer to [I-D.dekater-scion-pki], [I-D.dekater-scion-controlplane], and [I-D.dekater-scion-dataplane]. A more detailed analysis of relationships and dependencies between components is available in [I-D.rustignoli-scion-components]. "Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE)", Gyan Mishra, Jeff Tantsura, Mankamana Mishra, Sudha Madhavi, Adam Simpson, Shuanglong Chen, 2023-10-22, As operators migrate from an IPv4 core to an IPv6 core for global table internet routing, 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 Core Underlay Network. "EVPN Mpls Ping Extension", DIKSHIT Saumya, Gyan Mishra, Srinath Rao, Santosh Easale, Ashwini Dahiya, 2023-11-19, 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, 2023-11-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 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]. "BGP Extensions of SR Policy for Headend Behavior", Changwang Lin, Jiang Wenying, Yisong Liu, Mengxiao Chen, Hao Li, 2023-12-08, This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. "Extensible In-band Processing (EIP) Architecture and Framework", Stefano Salsano, Hesham ElBakoury, Diego Lopez, 2023-12-21, 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, 2024-01-08, 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, 2024-03-17, 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. "Credentials Provisioning and Management via EAP (EAP-CREDS)", Massimiliano Pala, Yuan Tian, 2023-11-27, With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. Usually, credentails used in an access network can be in different levels (e.g., network-level, user-level) and sometimes tend to live unmanaged for quite a long time due to the challenges of operation and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/ authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. "Secure IP Binding Synchronization via BGP EVPN", DIKSHIT Saumya, Gadekal, Reddy, 2024-01-03, 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. "Path MTU (PMTU) for Segment Routing (SR) Policy", Shuping Peng, Dhruv Dhody, Ketan Talaulikar, Gyan Mishra, 2024-01-07, 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. "Destination/Source Routing", David Lamparter, Anton Smirnov, Jen Linkova, Shu Yang, Mingwei Xu, 2024-01-31, 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 [RFC2460] 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. "Stub Router Flag in ICMPv6 Router Advertisement Messages", Jonathan Hui, 2024-02-27, This document defines a new Stub Router flag in the Router Advertisement message that can be used to distinguish configuration information sent by stub routers from information sent by infrastructure routers. "Usecases of SRv6 Based Computing Interconnection Network", Xiaoqiu Zhang, Feng Yang, Weiqiang Cheng, Zhihua Fu, 2023-10-18, The requirements of computing interconnection are increasingly attracting the attention of service providers. They have been thinking about how to leverage their network advantages to provide integrated networking and computing services. This document describes some scenarios of using SRv6 based network technology which can partially meet the service requirement of computing interconnection. "Use Cases for Parent SR Policy", Jiang Wenying, Weiqiang Cheng, Changwang Lin, Yuanxiang Qiu, 2024-01-05, 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 dynamic, explicit or composite. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment. "Intra-domain SAVNET method", Dan Li, Libin Liu, Changwang Lin, Xueyan Song, Yuanxiang Qiu, 2024-01-05, This document proposes a method of Source Address Validation in Intra-domain, which can be applied to OSPF and IS-IS protocols. By extending IGP and adding the protocol calculation procedure, the SAV rule can be accurately calculated to realize the source address verification. "NRP ID in SRv6 segment", Yisong Liu, Changwang Lin, Hao Li, Liyan Gong, 2023-11-08, This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. "Considerations about Generalized IETF Network Slicing", Zhenbin Li, Jie Dong, Jing Gao, 2023-10-20, IETF network slice has been introduced to meet specific service requirements, such as the connectivity requirements and the associated network capabilities such as bandwidth, latency, jitter and network functions with the resource behaviors such as computing and storage availability. For the realization of IETF network slices, one or more network resource partitions (NRPs) can be created in the network. Each NRP is a collection of network resources (buffer, queuing, scheduling, etc.) allocated in the underlay network. The connectivity constructs from one or more IETF network slices can be mapped to an NRP. NRP specific identifiers could be carried in the IETF network slice packets, which could be used to determine the set of network resources to be used for the processing and forwarding of the packets in the corresponding NRP. With the development of IETF network slicing technologies and the deployment of IETF network slices in different types of networks, there are emerging requirements about the new capability and functionality of IETF network slices. To meet those requirements, it is expected that the concept IETF network slice and NRP needs be generalized. This document describes the considerations about possible generalization of IETF network slice and NRP. "Segment Routing based Solution for Hierarchical IETF Network Slices", Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Jie Dong, Ran Chen, Yanrong Liang, 2024-01-07, This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. "Generalized Arguments of SRv6 Segment", Zhenbin Li, Jianwei Mao, Cheng Li, 2023-11-20, This document analyzes the challenges of Arguments of SRv6 SID, and the chance of using Arguments of SRv6 SID to reduce the length of the IPv6 extension header. According to these analysis, this document specifies a kind of generalized and structured Arguments for SRv6 SID, which can carry multiple Arguments parts for a SRv6 SID. "DetNet Enhanced Data Plane", Xuesong Geng, Tianran Zhou, Li Zhang, Zongpeng Du, 2023-10-23, Aiming at providing the bounded latency to DetNet services, DetNet data plane is required to be enhanced. This document provides a method to extend DetNet data plane by introducing the Bounded Latency Information (BLI), which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. "PCEP for Enhanced DetNet", Li Zhang, Xuesong Geng, Tianran Zhou, 2024-02-29, PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane. "IGP Extensions for Advertising Node Index", Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2024-01-10, 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, 2024-01-10, 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, 2023-10-22, 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. "Distributed Learning Architecture based on Edge-cloud Collaboration", Chao Li, 4875690059616E67, Zhengjie Sun, Sheng Liu, Haomian Zheng, 2024-01-22, This document describes the distributed learning architecture based on edge-cloud collaboration. "An Overview of Energy-related Effort within the IETF", Toerless Eckert, Mohamed Boucadair, Pascal Thubert, Jeff Tantsura, Carlos Pignataro, 2024-01-05, This memo provides an overview of work performed by or proposed within the IETF related to energy and/or green: awareness, management, control or reduction of consumption of energy, and sustainability as it related to the IETF. This document is written to help those unfamiliar with that work, but interested in it, in the hope to raise more interest in energy- related activities within the IETF, such as identifying gaps and investigating solutions as appropriate. This document captures work until 12/2022, at which time the "IAB workshop on Environmental Impact of Internet Applications and Systems" revived interest and triggered new work in the topic within the IETF/IRTF. "Performance-Oriented Digital Twins for Packet and Optical Networks", Albert Cabellos, Christopher Janz, 2023-10-23, This draft introduces the concept of a Network Digital Twin (NDT), including the architecture as well as the interfaces. Then two specific instances of the NDT are introduced, the first one for packet networks. This produces performance estimates (delay, jitter, loss) for a packet network with a specified topology, traffic demand, and routing and scheduling configuration. Second, a NDT for optical networks, this produces transmission performance estimates of an optical network with specified optical service topologies and network equipment types, topology and status. "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, 2024-03-04, 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. "BIER Extension Headers", Zhaohui Zhang, Xiao Min, Yisong Liu, Hooman Bidgoli, 2024-02-25, Bit Index Explicit Replication (BIER) is a multicast technology with a new encapsulation and forwarding paradigm. BIER encapsulation is specified in RFC8296, and this document specifies extension headers used with BIER encapsulation header. "A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information", Donald Eastlake, Haoyu Song, 2023-11-20, 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. "Problem statement for Inter-domain Intent-aware Routing using Color", Shraddha Hegde, Dhananjaya Rao, Jim Uttaro, Alex Bogdanov, Luay Jalil, 2023-10-23, 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. "I2NSF Analytics Interface YANG Data Model", Patrick Lingga, Jaehoon Jeong, Yunchul Choi, 2024-02-07, 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 system in a Network Functions Virtualization (NFV) environment. The YANG data model described in this document is based on the I2NSF NSF- Facing Interface and the I2NSF Monitoring Interface for enabling the delivery of analytics information based on monitoring data received from a Network Security Function (NSF). "Encryption algorithm Rocca-S", Yuto Nakano, Kazuhide Fukushima, Takanori Isobe, 2024-01-24, This document defines Rocca-S encryption scheme, which is an Authenticated Encryption with Associated Data (AEAD), using a 256-bit key and can be efficiently implemented utilizing the AES New Instruction set (AES-NI). "A Larger Internet Key Exchange version 2 (IKEv2) Payload", Yoav Nir, 2024-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. "IBM i Telnet Enhancements", Russel Garvey, Barbara Smith, Timothy Mullenbach, 2023-11-21, This obsoletes RFC4777 with an enhanced Automatic Sign-On PBKDF2 with HMAC SHA-512 password hash available with systems running with V7R5M0 or later and configured to use Password Level (QPWDLVL) 4 or higher for the user profile passwords Section 5.3. Require use of Transport Layer Security (TLS) to secure the telnet session between the Telnet server and client Section 13. Add Telnet Device Negotiation Termination Section 10.5 documenting how telnet clients that do not follow 5250 negotiation are handled. Document use of Transport Layer Security (TLS) using port 992 Section 14. Enhancement to add Multi Factor Authentication to automatic sign-on Changes since -00 Draft * Update abstract for PBKDF2 with HMAC SHA-512 password hash * Document use of Transport Layer Security (TLS) in Security Considerations Section 13 Changes since -01 Draft * TLS handshake must complete before invite for terminal type is sent in Section 2 * Change using TLS from RECOMENDED to REQUIRED to be ccompliant with this draft Section 13 * Change disabling port 23 from RECOMENDED to REQUIRED Section 13 * Detail use and related DCM configuration for TLS Section 13 * Add IANA Considerations use of port 992 for Telnet using TLS/SSL (service telnet-ssl) to Section 14 * Include "application definition" and "Digital Certificate Manager (DCM)" to Section 1.1 * Update abstract for Authentication factor in Section 5 * Update Response Codes for Authentication factor in Section 10.4 "Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)", Greg Mirsky, 2023-09-27, 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. "DAP Interoperation Test Design", David Cook, 2024-02-28, This document defines a common test interface for implementations of the Distributed Aggregation Protocol for Privacy Preserving Measurement (DAP) and describes how this test interface can be used to perform interoperation testing between the implementations. Tests are orchestrated with containers, and new test-only APIs are introduced to provision DAP tasks and initiate processing. "Remove SHA-1 from active use within DNSSEC", Wes Hardaker, Warren Kumari, 2024-02-27, This document retires the use of SHA-1 within DNSSEC. "The Transit Measurement Option", Tal Mizrahi, Tianran Zhou, Shahar Belkar, Reuven Cohen, 2024-02-13, 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. "DNSSEC Cryptographic Algorithms", Wes Hardaker, Warren Kumari, 2024-02-27, [EDITOR NOTE: This document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in [RFC8624]; that is the work of future documents. Instead, this document moves the canonical list of algorithms from [RFC8624] to an IANA registry. This is done for two reasons: 1) to allow the list to be updated more easily, and, much more importantly, 2) to allow the list to be more easily referenced.] 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 updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs. "Real-Time Monitoring Link/Protocol Neighbor State", Tianran Zhou, Feng Xu, Shunwan Zhuang, Haibo Wang, Cao Diao, 2023-10-23, Various protocols are deployed in today's networks, such as BGP / ISIS / OSPF etc. Link neighbor state changes and protocol neighbor state changes are the most important network events that need to be processed with the highest priority. In particular, the SDN controller needs to quickly sense the link neighbor and protocol neighbor state change information in the network. Thus, the various policies applied by the SDN controller to the network can quickly match the current state of the network. This document discusses some possible scenarios and the relevant requirements. "Cisco's CoAP Simple Management Protocol", Paul Duffy, 2023-12-11, 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, 2024-02-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. "Kyber Post-Quantum KEM", Peter Schwabe, Bas Westerbaan, 2024-01-02, This memo specifies a preliminary version ("draft00", "v3.02") of Kyber, an IND-CCA2 secure Key Encapsulation Method. 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://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg- schwabe-kyber.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/draft-schwabe-cfrg-kyber. "Publicly Verifiable Nominations Committee (NomCom) Random Selection", Donald Eastlake, 2023-12-31, This document describes a method for making random selections in such a way as to promote public confidence in the unbiased nature of the choice. This method is referred to in this document as "verifiable selection". It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar techniques could be and have been applied to other selections. It provdes an optional extension for multiple rounds of such selection that can be induced by earlier selectees without compromising the unpredictable nature of the selections. This document obsoletes RFC 3797. "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", Michael Tuexen, Randall Stewart, 2024-03-03, 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. "SCION Control-Plane PKI", Corine de Kater, Nicola Rustignoli, Samuel Hitz, 2024-03-04, This document presents the trust concept and design of the SCION _control-plane Public Key Infrastructure (PKI)_, SCION's public key infrastructure model. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture. The control-plane PKI, or short CP-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 builds the basis for SCION's special trust model based on so-called Isolation Domains. This document first introduces the trust model behind the SCION's control-plane PKI, as well as clarifications to the concepts used in it. This is followed by specifications of the different types of certificates and the Trust Root Configuration. The document then specifies how to deploy the whole infrastructure. "Distributed Flow Measurement in IPv6", Haojie Wang, sijun weng, Changwang Lin, Xiao Min, Greg Mirsky, 2024-01-08, 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. "SAV-based Anti-DDoS Architecture", Yong Cui, Jianping Wu, Linzhe Li, Lei Zhang, 2024-03-04, Existing SAV schemes can not effectively defend against IP Spoofing DDoS under incremental deployment. This document proposes SAV-D, a savnet based distributed defense architecture to enhance SAV's defense. The main idea of SAV-D is to collect and aggregate more threat data from existing SAV devices and then distribute crucial knowledge to widespread devices, thus significantly expanding defense across the entire network. "Delegation based Device Onboarding using PoA Authorization", Sreelakshmi Sudarsan, Olov Schelen, Ulf Bodin, 2023-10-20, Industrial network layer onboarding demands a technique that is efficient, scalable, and secure. In this document, we propose a delegation-based device onboarding technique using Power of Attorney (PoA) based authorization. This enables manufacturers to send the device to the right device owner manage the ownership transfer through the supply chain and eventually resell the device to a new owner. "Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle", Changwang Lin, Zhenqiang Li, Ran Pang, Ketan Talaulikar, Mengxiao Chen, 2024-03-16, 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. "Yang Data Model for EVPN multicast", Hongji Zhao, Yisong Liu, Xufeng Liu, Mani Panchanathan, Mahesh Sivakumar, 2023-10-19, 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. "Supporting In-Situ OAM Direct Export Using MPLS Network Actions", Greg Mirsky, Mohamed Boucadair, Tony Li, 2023-09-27, In-Situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information that can be used to calculate various performance metrics. IOAM Direct Export (IOAM-DEX) is one of the IOAM Option types, 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. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the on-path operational state, and telemetry information can be collected using IOAM-DEX Option in combination with MNA. "The Requirements for Secure Routing Path", Meiling Chen, Li Su, 2023-11-16, Both ISPs and users have put forward requirements for secure routing, the scenarios are analyzed in the draft draft-chen-secure-routing- use-cases (https://datatracker.ietf.org/doc/draft-chen-secure- routing-use-cases/). This draft analyzes the functions required to implement secure routing. Attack detection and users security requirements translateion are out of scope. "Transfer Digital Credentials Securely", Dmitry Vinokurov, Yogesh Karandikar, Matthias Lerch, Alex Pelletier, Nick Sha, 2023-10-10, Digital Credentials allow users to access Homes, Cars or Hotels using their mobile devices. Once a user has a Credential on a device, sharing it to others is a natural use case. This document describes a sharing flow that allows convenient and seamless user experience, similar to sharing other digital assets like photos or documents. The sharing process should be secure and private. This document also defines a new transport to meet unique requirements of sharing a Credential. "Replay Resistant Authenticated Receiver Chain", Wei Chuang, Bron Gondwana, 2024-02-20, DKIM (RFC6376) is an IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit. Section 8.6 defines a vulnerability called DKIM Replay as a spam message sent through a SMTP MTA DKIM signer, that then is sent to many more recipients, leveraging the reputation of the signer. We propose a replay resistant cryptographic based protocol that discloses all SMTP recipients and signs them, allowing a receiver or any third party to verify that the message went to the intended recipient. If not then then potentially the message is replayed. Moreover it leverages ARC (RFC8617) and sender defined forwarding path to build a "chain of custody" that accurately defines the SMTP forwarding path of the message. This also allows the protocol to detect DKIM and ARC replay attacks and other attacks. "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, 2024-01-05, 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. "In-band Task Provisioning for DAP", Shan Wang, Christopher Patton, 2024-02-06, An extension for the Distributed Aggregation Protocol (DAP) is specified that allows the task configuration to be provisioned in- band. "The Hypertext Transfer Protocol Attestable (HTTPA) Version 2", Hans Wang, Gordon King, Nick Li, Ned Smith, Krzysztof Sandowicz, 2023-11-04, The Hypertext Transfer Protocol Attestable version 2 (HTTPA/2) is an HTTP extension. It is a transaction-based protocol agnostic to Transport Layer Security (TLS) in which the Trusted Execution Environment (TEE) is considered a new type of requested resource over the Internet. The original Hypertext Transfer Protocol Attestable (HTTPA) (referred to as HTTPA/1 in the rest of the document) includes remote attestation (RA) process onto the HTTPS protocol in the assumption of using Transport Layer Security (TLS) across the Internet. In contrast, the design of HTTPA/2 could establish a trusted (attested) and more secure communication without dependence on TLS. The definition of Attestation for the purposes of this draft: The process of vouching for the accuracy of TEE based services, configuration, and data where the TEE conveys Evidence about its environment, roots of trust and protected functions. The Evidence is a digital expression of TEE trustworthiness. "A Blockchain Trusted Protocol for Intelligent Communication Network-02", Zhe Tu, Hua-chun Zhou, Haoxiang Song, Yuzheng Yang, Jingfu Yan, 2023-10-11, This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. "Additional addresses for QUIC", Maxime Piraux, Olivier Bonaventure, 2024-03-04, This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", David Noveck, 2023-11-06, This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It obsoletes and replaces RFC5662. "The Incident Detection Message Exchange Format version 2 (IDMEFv2)", Gilles Lehmann, 2023-10-11, 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. "Service Affinity Solution for TCP based Application", Wei Wang, Aijun Wang, 2024-03-17, This draft proposes a service affinity solution between client and server based on the newly defined TCP Options. This solution can avoid the waste of resources caused by saving a large amount of customer status data in the network equipment, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing-aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources. "Mappings Between XML2RFC v3 and AsciiDoc", Marc Petit-Huguenin, 2024-01-27, 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, 2023-11-17, This document specifies a compressed 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, 2024-02-27, The Concise Data Definition Language (CDDL) today is defined by RFC 8610 and RFC 9165. 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 based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. It is intended to serve as a basis for prototypical implementations of CDDL 2.0. This document is intended to evolve over time; it might spawn specific documents and then retire or eventually be published as a roadmap document. "Group Policy ID BGP Extended Community", Wen Lin, John Drake, Dhananjaya Rao, 2023-10-20, 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 specification 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 node when the optimization of network bandwidth is desired. "Media Handling Considerations for Wireless Networks", John Kaippallimalil, Sri Gundavelli, Spencer Dawkins, 2024-02-14, Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. "The JSON format for vCon - Conversation Data Container", Daniel Petrie, Thomas McCarthy-Howe, 2024-03-04, 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]) "Design Space Analysis of MoQ", Hang Shi, Yong Cui, Xiaobo Yu, 2024-03-03, This document investigates potential solution directions within the charter scope of MoQ WG. MoQ aims to provide low-latency, efficient media delivery solution for use cases including live streaming, gaming and video conferencing. To achieve low-latency media transfer efficiently, the network topology of relay nodes and the computation done at the relay nodes should be considered carefully. This document provides the analysis of those factors which can help the design of the MoQ protocols. "LSP Ping/Traceroute for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, 2023-09-24, This document describes the MPLS Node IOAM Information Query functionality, which uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. "Encapsulation of BFD for SRv6 Policy", Yisong Liu, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Xiao Min, 2024-03-04, 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. "Forward Erasure Correction for QUIC loss recovery", Francois Michel, Olivier Bonaventure, 2023-10-23, This documents lays down the QUIC protocol design considerations needed for QUIC to apply Forward Erasure Correction on the data sent through the network. "An EAT-based Key Attestation Token", Mathias Brossard, Thomas Fossati, Hannes Tschofenig, 2024-03-04, This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. "Stateless Best Effort Multicast Simulations", Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu, 2023-10-22, 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. "Computing Segment for Service Routing in SAN", Fenlin Zhou, Dongyu Yuan, Dong Yang, 2023-10-17, Since services provisioning requires delicate coordination among the client, network and cloud, this draft defines a new Segment to provide service routing and addressing functions by leveraging SRv6 Segment programming capabilities. With Computing Segments proposed, the network gains its capability to identify and process a SAN header in need and a complete service routing procedure can be achieved. "BGP for Mirror Binding", Huaimo Chen, Bruno Decraene, Gyan Mishra, Yanhe Fan, Aijun Wang, Xufeng Liu, 2023-11-10, BGP is used to distribute a binding to a node. The binding includes a binding SID and a path represented by a list of SIDs. This document describes extensions to BGP for distributing the information about the binding to a protecting node. For an SR path via the node with the binding SID, when the node fails, the protecting node such as the upstream neighbor on the path uses the information to protect the binding SID of the failed node. "PCE for Mirror Binding", Huaimo Chen, Bruno Decraene, Gyan Mishra, Aijun Wang, Xufeng Liu, Lei Liu, 2023-10-08, PCE is used to distribute a binding to a node. The binding includes a binding SID and a path represented by a list of SIDs. This document describes extensions to PCEP for distributing the information about the binding to a protecting node. For an SR path via the node with the binding SID, when the node fails, the protecting node such as the upstream neighbor on the path uses the information to protect the binding SID of the failed node. "Requirements and Design for Interfaces of Network Digital Twin", Danyang Chen, Hongwei Yang, Cheng Zhou, 2024-03-04, The interfaces of Digital Twin Network can be divided as twin network southbound interface, internal interface and northbound interface. In order to build a digital twin network and realize its many advantages, different interfaces should be able to meet different requirements. And this memo introduces the requirements and design about interfaces of the Digital Twin Network. "General Source Address Validation Capabilities", Mingqing(Michael) Huang, Weiqiang Cheng, Dan Li, Nan Geng, Mingxing Liu, Li Chen, Changwang Lin, 2024-03-03, 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. "Intra-domain Source Address Validation (SAVNET) Architecture", Dan Li, Jianping Wu, Lancheng Qin, Nan Geng, Li Chen, Mingqing(Michael) Huang, Fang Gao, 2024-03-16, 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 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 rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. "Inter-domain Source Address Validation (SAVNET) Architecture", Dan Li, Jianping Wu, Mingqing(Michael) Huang, Li Chen, Nan Geng, Libin Liu, Lancheng Qin, 2024-03-04, 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. "Generalized IPv6 Tunnel for QUIC", Zhenbin Li, Shuanglong Chen, Hang Shi, 2024-01-10, This document defines a new encapsulation method for QUIC packet transmission based on IPv6 extension headers. This method enables QUIC packet transmission to easily inherit the extended functions of IPv6. "BFD Extension for DetNet Remote Defect Indication (RDI)", Hongyi Huang, Li Zhang, Tianran Zhou, 2024-02-21, This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. "BGP-LS Advertisement of TE Policy Performance Metric", Changwang Lin, Mengxiao Chen, Hao Li, 2023-12-20, 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, 2024-03-04, 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. "YANG Data Model for RPKI to Router Protocol", Yisong Liu, Changwang Lin, Haibo Wang, Hongwei Liu, Di Ma, 2023-12-08, This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). "Reliability Considerations of Path-Aware Semantic Addressing", Guangpeng Li, Zhe Lou, Luigi Iannone, 2024-03-04, Path-Aware Semantic Address (PASA), proposes to algorithmically assign addresses to nodes in a 6lo environment so to achieve stateless forwarding, hence, allowing to avoid using a routing protocol. PASA is more suitable for stable and static wireline connectivity, in order to avoid renumbering due to topology changes. Even in such kind of scenarios, reliability remains a concern. This memo tackles specifically reliability in PASA deployments, analyzing possible broad solution categories to solve the issue. "Basic Support for IPv6 Networks Operating over 5G Vehicle-to-Everything Communications", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Alexandre Petrescu, Sandra Cespedes, 2023-10-23, This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to the existing IPv6 protocol stack. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 in more complex 5G scenarios are not covered in this specification and are a subject for future work. "Intent-Based Network Management Automation in 5G Networks", Jaehoon Jeong, Yoseop Ahn, Younghan Kim, J., PARK, 2023-11-06, 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). "Requirement of Fast Fault Detection for IP-based Network", Liang Guo, Yi Feng, Jizhuang Zhao, Fengwei Qin, Lily Zhao, Haibo Wang, Wei Quan, Hongyi Huang, 2024-03-01, The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. This document describes the requirements for a fast fault detection solution of IP-based network. "Echo Request/Reply for DetNet Capability Discovery", Li Zhang, Hongyi Huang, Tianran Zhou, 2024-02-18, This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions. "IPsec and IKE anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing", Paul Ponchon, Mohsin Shaikh, Hadi Dernaika, Pierre Pfister, Guillaume Solignac, 2023-10-23, This document discusses the challenges of running IPsec with anti- replay in multi-core environments where packets may be re-ordered (e.g., when sent over multiple IP paths, traffic-engineered paths and/or using different QoS classes). A new solution based on splitting the anti-replay sequence number space into multiple different sequencing subspaces is proposed. Since this solution requires support on both parties, an IKE extension is proposed in order to negotiate the use of the anti-replay sequence number subspaces. "A YANG Network Data Model of Network Inventory", Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair, 2023-10-19, This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models. This document is meant to help IVY base Network Inventory model discussion and ease agreement on a base model that would be flexible enough to be augmented with components that are covered by the IVY Charter. The hardware components definition are adapted from draft-ietf-ccamp- network-inventory-yang-02. "Comcast ISP Low Latency Deployment Design Recommendations", Jason Livingood, 2023-09-28, The IETF's Transport Area 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 do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment design decisions are ultimately left to implementers. This document explores the potential implications of key deployment design decisions and makes recommendations for those decisions that may help drive adoption. "BGP over QUIC", Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura, 2024-03-03, This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency. "A Taxonomy of Internet Consolidation", Mark McFadden, 2023-10-23, This document contributes to the ongoing discussion surrounding Internet consolidation. At recent IETF meetings discussions about Internet consolidation revealed that different perspectives gave completely different views of what consolidation means. While we use the term consolidation to refer to the process of increasing control over Internet infrastructure and services by a small set of organizations, it is clear that that control is expressed through economic, network traffic and protocol concerns. As a contribution to the discussion surrounding consolidation, this document attempts to provide a taxonomy of Internet consolidation with the goal of adding clarity to a complex discussion. "MicroTap Segment in Segment Routing", Zhaohui Zhang, Ryan Hoffman, Gurminderjit Bajwa, Dan Voyer, Shay Zadok, Aijun Wang, Luay Jalil, Li, Siva Sivabalan, 2024-02-21, This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. "Framework of Fast Fault Detection for IP-based Network", Haibo Wang, Fengwei Qin, Lily Zhao, Shuanglong Chen, Hongyi Huang, 2024-03-01, The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. IP-based storage network is the typical usage of that scenario. When the IP-based storage network fault occurs, NVMe connections need to be switched over. Currently, no effective method is available for quick detection, switchover is performed only based on keepalive timeout, resulting in low performance. This document defines the basic framework of how network assisted host devices can quickly detect application connection failures caused by network faults. "INIT Forwarding for the Stream Control Transmission Protocol", Michael Tuexen, Timo Voelker, 2023-10-08, 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, 2023-10-23, 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. "Composite Token Claims", Chris Lemmons, 2023-10-23, Composition claims are CBOR Web Token claims that define logical relationships between sets of claims and provide for private claim values via encryption. "Modelling Boundaries", Nigel Davis, 2024-03-16, Current modelling techniques appear to have boundaries that make representation of some concepts in modern problems, such as intent and capability, challenging. The concepts all have in common the need to represent uncertainty and vagueness. The challenge results from the rigidity of boundary representation, including the absoluteness of instance value and the process of classification itself, provided by current techniques. When describing solutions, a softer approach seems necessary where the emphasis is on the focus on a particular thing from a particular perspective. Intelligent control (use of AI/ML etc.) could take advantage of partial compatibilities etc. if a softer representation was achieved. The solution representation appears to require * Expression of range, preference and focus as a fundamental part of "A Collaborative Framework for Cyberspace Governance: the Internet of Governance", Jilong Wang, Yi Qiao, 2023-10-22, This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples. "The "dereferenceable identifier" pattern", Carsten Bormann, Christian Amsuess, 2024-03-02, 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 -03 revision discusses the continuum between entirely // relying on the result of dereferencing an identifier and building // in knowledge of all expected identifiers, and it mentions further // pitfalls of using dereferenceable identifiers. "MIMI Delivery Service", Raphael Robert, Konrad Kohbrok, 2023-11-06, This document describes the MIMI Delivery Service. "Handling Encrypted DNS Server Redirection", John Todd, Tommy Jensen, Corey Mosher, 2024-03-04, 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. "k-of-n Composite Signatures for Multi-Algorithm PKI", Massimiliano Pala, Jan Klaussner, Mike Ounsworth, John Gray, 2023-12-04, With the need to evolve the cryptography used in today applications, devices, and networks, there are many scenarios where the use of a single-algorithm is not sufficient. For example, there might be the need for migrating between two existing algorithms because of a weakening of earlier generations (e.g., from classic or traditional to post-quantum or quantum-safe). Another example might involve the need to test, instead, the capabilities of devices via test drivers and/or non-standard algorithms. Another very common case is the need to combine certified cryptography (e.g., FIPS) with newer algorithms that are not yet certified or that are not planned for certification. This work extends the options provided by Explicit Composite, defined in [I-D.ounsworth-pq-composite-sigs], by providing a mechanism to manage backward and forward compatibility via k-of-n signature validation procedures. This document provides the definition of a new type of the kofn- CompositePublicKey and kofn-CompositeSignature which are aligned with the definitions of the respective structures for Explicit Composite [I-D.ounsworth-pq-composite-sigs]. "Flag-based MPLS On Path Telemetry Network Actions", Haoyu Song, Giuseppe Fioccola, Rakesh Gandhi, 2024-03-04, This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks. "Group Address Allocation Protocol (GAAP)", Dino Farinacci, Mike McBride, 2023-09-28, 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. "SRv6 Upper-Layer Checksum", Xiao Min, Yao Liu, Chongfeng Xie, Yisong Liu, 2023-11-05, This document defines SRH C-flag and its processing, which makes the IPv6 upper-layer checksum computation rule applicable to both compressed and uncompressed SRv6 SIDs. "Defined-Trust Transport (DeftT) Protocol for Limited Domains", Kathleen Nichols, Van Jacobson, Randy King, 2023-10-04, This document describes a broadcast-oriented, many-to-many Defined- trust Transport (DeftT) framework that makes it simple to express and enforce application and deployment specific integrity, authentication, access control and behavior constraints directly in the protocol stack. DeftT's communication model is one of synchronized collections of secured information rather than one-to- one optionally secured connections. DeftT is part of a Defined-trust Communications approach with a specific example implementation available. Combined with IPv6 multicast and modern hardware-based methods for securing keys and code, it provides an easy to use foundation for secure and efficient communications in Limited Domains (RFC8799), in particular for Operational Technology (OT) networks. "EDNS Presentation and JSON Format", Libor Peltan, Tom Carpay, 2023-10-19, This document describes the textual and JSON representation formats of EDNS options. It also modifies the escaping rules of the JSON representation of DNS messages, previously defined in RFC8427. "Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)", Mike Ounsworth, Aron Wussler, Stavros Kousidis, 2024-01-31, The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number of key shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical split- key PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. "An sdfType for Links", Carsten Bormann, 2023-12-03, This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). "The Gordian Envelope Structured Data Format", Wolf McNally, Christopher Allen, 2024-02-18, 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. "IANA Registry for IMAP Extended SEARCH Return Options and Data Tags", Kenneth Murchison, 2023-10-23, This document creates a registry of IMAP Extended Search Return Options and Data Tags (RFC 4466) in order to help developers and IMAP extension writers track interactions between different extensions. Open Issues * Is Expert Review the correct registration policy? * Should we also add a registry of SEARCH criteria? "Gap Analysis for Enhanced DetNet", Quan Xiong, Aihua Liu, 2024-02-25, From charter and milestones, the enhanced Deterministic Networking (DetNet) is required to provide the enhancement of flow identification and packet treatment for data plane to achieve the DetNet QoS in large-scale networks. This document discusses the characteristics of scaling deterministic networks and analyzes the gaps of the existing technologies especially applying the DetNet data plane as per RFC8938. "A Pre-Authentication Mechanism for SSH", Peter Gutmann, 2023-12-21, 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, 2024-01-20, This document defines an ontology that describes the specifications published by the RFC Editor, together with ancillary documents. "PCEP Extensions to support BFD parameters", Orly Bachar, Marina Fizgeer, 2023-12-04, 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. "Deterministic Networking (DetNet) Controller Plane - VPFC Planning Information Model Based on VPFP in Scaling Deterministic Networks", Daorong Guo, Guangliang Wen, Kehan Yao, Quan Xiong, Guoyu Peng, YOU Xuejun, zhushiyin, 2024-01-05, The cycle-based queuing and forwarding mechanisms are an effective method to ensure that the transmission has a definite upper bound of jitter, as well as latency. The prerequisite for this method is to ensure that queuing resources do not conflict. In scaling deterministic networks, how to avoid the queuing resources conflict of this method is an open problem. This document proposes the information model of planning virtual periodic forwarding channel (VPFC) based on virtual periodic forwarding path (VPFP). The solution can solve the queuing resources conflict of cycle-specified queuing and forwarding in nonlinear topology domain, ensuring the bounded latency of DetNet flow in the same periodic forwarding domain. "mLDP/RSVP-TE P2MP Tunnel with SRv6 SID", Zhaohui Zhang, Vishnu Beeram, Rishabh Parekh, IJsbrand Wijnands, Ran Chen, 2024-02-06, This document specifies extensions to mLDP and RSVP-TE P2MP protocols to set up mLDP and RSVP-TE P2MP tunnels with SRv6 SIDs intead of MPLS labels. "Static Multicast Distribution Trees", tathagata nandy, Anil Raj, Muthukumar, Subramanian, 2024-01-08, This document specifies the Static Provision of Multicast route as an alternate to Layer 3 Multicast protocols like PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM SSM (Source-Specific Multicast), or PIM BIDI (Bidirectional). It works like a standalone Multicast Route provisioning feature that can interoperate with other dynamic Multicast protocols like PIM-SM or with L2 protocols like IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery). This feature can function with/without the use of Unicast Routing Protocols to build the Multicast tree. "Interconnecting domains with Multiprotocol IBGP", Krzysztof Szarkowicz, Israel Means, Moshiko Nayman, 2023-10-17, This document relaxes the constraints specified in [RFC4364] and [RFC4456] allowing the building of Inter-domain L3VPN architecture with Multiprotocol internal BGP. "Considerations for Protection of SR Networks", Yao Liu, Weiqiang Cheng, Changwang Lin, Xuesong Geng, Yisong Liu, 2024-01-09, This document describes the considerations for protection of Segment Routing (SR) networks. "DNS-Based Multicast Stream Discovery", Nathan Karstens, Dino Farinacci, Mike McBride, 2023-11-06, This document describes an application of DNS-SD for the advertisement and discovery of multicast streams. This is especially useful with multicast streams that use a dynamically-assigned multicast address. "Compact ECDHE and ECDSA Encodings for TLS 1.3", John Mattsson, Hannes Tschofenig, 2024-02-23, The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. "Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol", Marc Blanchet, 2024-03-04, 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. "Requirements for a Network Quality Framework Useful for Applications, Users, and Operators", Bjorn Teigen, Magnus Olden, 2023-10-18, This document describes the features and attributes a network quality framework must have to be useful for different stakeholders. The stakeholders included are developers of Applications, End-Users, and Network Operators and Vendors. At a high level, End-Users need an understandable network metric. Application developers need a network metric that allows them to evaluate how well their application is likely to perform given the measured network performance. Network Operators and Vendors need a metric that facilitates troubleshooting and optimization of their networks. Existing network quality metrics and frameworks typically address the needs of one or two of these stakeholders, but we have yet to find one that bridges the needs of all three. "Bundle Protocol Endpoint ID Patterns", Brian Sipos, 2023-10-06, 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 CBOR encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its CBOR 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. "YANG model for NETCONF Event Notifications", Alex Feng, Pierre Francois, Thomas Graf, Benoit Claise, 2024-01-21, This document defines the YANG model for NETCONF Event Notifications. The definition of this YANG model allows the encoding of NETCONF Event Notifications in YANG compatible encodings such as YANG-JSON and YANG-CBOR. "Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol", Marc Blanchet, 2024-03-04, 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, 2023-12-22, 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, 2024-02-03, 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 (C-SID) for SRv6 SFC", Cheng Li, Weiqiang Cheng, Hongyi Huang, 2024-02-29, 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(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming. "BIER with Anycast", Zhaohui Zhang, IJsbrand Wijnands, Zheng Zhang, Mankamana Mishra, Huaimo Chen, 2024-02-06, BIER architecture currently does not support anycast, in that each BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR- ID. BIER signaling protocols also check if there are duplicate BFR- IDs advertised. This document discusses and specifies anycast support with BIER. It updates RFC 8279, RFC 8401 and RFC 8444. "Timeslot Queueing and Forwarding Mechanism", Shaofu Peng, Peng Liu, Kashinath Basu, Aihua Liu, Dong Yang, Guoyu Peng, 2024-03-04, 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 in IP/MPLS networks, which we call timeslot queueing and forwarding (TQF) mechanism. It aims to bring timeslot resources to layer-3, to make it easier for the control plane to calculate the delay performance based on the timeslot resources, and also make it easier for the data plane to create more flexible timeslot mapping. The functions of TQF can better meet large scaling requirements. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2024-03-01, 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, 2023-09-25, 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 made of context addresses and references. These 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 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. "Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media", Srinivas Gudumasu, Ahmed Hamza, 2023-09-25, 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. "Managing CBOR numbers in Internet-Drafts", Carsten Bormann, 2024-02-29, 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 SR P2MP Policies and State using BGP-LS", Yisong Liu, Changwang Lin, Hooman Bidgoli, 2023-11-08, 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. "Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA)", Job Snijders, Ben Cartwright-Cox, 2023-10-23, 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. "Plaintext Sequence Numbers for Datagram Transport Security Layer 1.3", Boris Pismenny, 2023-10-19, This document specifies a TLS 1.3 extension that enables DTLS 1.3 to negotiate the use of plaintext sequence numbers instead of protected sequence numbers. Plaintext sequence numbers are advantageous in closed networks where the benefits of lower latency outweigh the risk of ossification and reduced privacy. "CDDL models for some existing RFCs", Carsten Bormann, 2024-02-27, 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. "Broadening the Scope of Encapsulating Security Payload (ESP) Protocol", Michael Rossberg, Steffen Klassert, Michael Pfeiffer, 2024-02-15, There are certain use cases where the Encapusalating Security Payload (ESP) protocol in its current form cannot reach its maximum potential regarding security, features and performance. Although these scenarios are quite different, the shortcomings could be remedied by three measures: Introducing more fine-grained sub-child-SAs, adapting the ESP header and trailer format, and allowing parts of the transport layer header to be unencrypted. These mechanisms are neither completely interdependent, nor are they entirely orthogonal, as the implementation of one measure does influence the integration of another. Although an independent specification and implementation of these mechanisms is possible, it may be worthwhile to consider a combined solution to avoid a combinatorial explosion of optional features. Therefore, this document does not yet propose a specific change to ESP. Instead, explains the relevant scenarios, details possible modifications of the protocol, collects arguments for (and against) these changes, and discusses their implications. "Using ALTO for exposing Time-Variant Routing information", Luis Contreras, 2024-02-27, 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. "EAT Attestation Results", Thomas Fossati, Eric Voit, Sergei Trofimov, 2023-10-23, 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. "An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness", Luis Contreras, Mohamed Boucadair, Diego Lopez, Carlos Bernardos, 2023-10-23, This document proposes an extension to the Cooperating Layered Architecture for Software-Defined Networking (SDN) by including compute resources and data analysis processing capabilities. "IPv6 Site connection to many Carriers", Nick Buraglio, Klaus Frank, Paolo Nero, Paolo Volpato, Eduard, 2024-01-29, Carrier resilience is a typical business requirement. IPv4 deployments have traditionally solved this challenge through private internal site addressing in combination with separate NAT engines attached to multiple redundant carriers. IPv6 brings support for true end-to-end connectivity on the Internet, and hence NAT is the least desirable option in such deployments. Native IPv6 solutions for carrier resiliency, however, have drawbacks. This document discusses all currently-available options to organize carrier resiliency for a site, their strengths and weaknesses, and provides a history of past IETF efforts approaching the issue. The views presented here are the summary of discussions on the v6ops mailing list and are not just the personal opinion of the authors. "BGP Flow-Spec Traffic Compress Action", Ming Shen, Wenyan Li, Lili Wang, Guoqiang Wang, 2023-10-22, 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, Gyan Mishra, Yuanxiang Qiu, 2024-02-21, 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. "Support of Hostname and Sequencing in YANG Notifications", Thomas Graf, Jean Quilbeuf, Alex Feng, 2024-01-14, This document specifies a new YANG module that augment the NETCONF Event Notification header to support hostname, Message Publisher ID and sequence numbers to identify from which network node and at which time the message was published. This allows the collector to recognize loss, delay and reordering between the publisher and the downstream system storing the message. "Computing Information Description in Computing-Aware Traffic Steering", Zongpeng Du, Yuexia Fu, Cheng Li, Daniel Huang, Zhihua Fu, 2023-10-23, This document describes the considerations and the potential architecture of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). "The Use Cases for Secure Routing Path", Meiling Chen, Li Su, Bo YANG, 2023-11-15, Current routing mechanism is based on the shortest path, which only take the link status and the path accessibility into consideration, without the security and trustworthiness of links and forwarding nodes. As security has become an important factor to the user. This paper proposes to add security factor in the routing process. With the frequent occurrence of security incidents, services security is an essential demand for the users. As there are many security devices in the ISP's network, this draft proposes secure routing mechanism. The purpose of secure routing is to converge security and routing to ensure the secure data transmission. The scope is transmission process security, while end-to-end security and application layer security are out of scope. "the extensions of BGP-LS to carry security capabilities", Meiling Chen, Li Su, 2024-03-04, As users' traffic faces more unpredictable attacks during transmission, there are more and more end-users now need high security data transmission guarantee, they need ISPs to provide security protection capabilities on the data forwarding path. Therefore, ISPs need to have real-time awareness of the security capabilities available in the network, then form a security capability map, finally provide security protection for users at the routing level. The goal of this draft is to collect the security capabilities of nodes, which will be one of the factors to form the routing topology, and use the routing programming capabilities to form a secure routing path. The security capability includes healthy information(such as the device software is up-to-date), security service information, device information(such as the manufacturer information of the equipment). 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, Mengxiao Chen, 2024-02-27, IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document describes the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. "Network Proactive Defense based on Source Address Validation", Weiqiang Cheng, Nan Geng, Dan Li, 1211176911910469110103, 2023-10-18, Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. "Signaling MPLS Readable Label Depth(RLD)", Yao Liu, 2023-09-18, This document defines a new type of MSD to reflect the Readable Label Depth(RLD), and the mechanism to signal this MSD using IGP and BGP- LS. "OAuth-PoA Grant Type", Sreelakshmi Sudarsan, Olov Schelen, Ulf Bodin, 2023-10-18, This draft proposes a new grant type for OAuth based on PoA-based authorization, that introduces a new role "principal" who controls the client, and enables the client to access resources owned by the resource owner via OAuth authorization server, on behalf of the principal, even if the principal is not online. "Positioning of PoA", Sreelakshmi Sudarsan, Olov Schelen, Ulf Bodin, 2023-10-18, Power of Attorney (PoA) based authorization is a generic and decentralized subgranting based authorization technique. In this, a principal can grant limited credibilities for an agent to act on its behalf for some limited time and context. This can be used in both constrained and non-constrained environments. PoA is a self- contained document that a principal sign and directs to an agent, thereby providing it the power to execute user actions on behalf of the principal for a predefined time. In this document, we compare PoA based authorization with different existing internet protocols for authorization and the relation with existing identity solutions. "An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation", Ke Xu, Jianping Wu, Yangfei Guo, Benjamin Schwartz, Haiyang Wang, 2023-10-23, This document presents RISAV, a protocol for establishing and using IPsec security between Autonomous Systems (ASes) using the RPKI identity system. In this protocol, the originating AS adds authenticating information to each outgoing packet at its Border Routers (ASBRs), and the receiving AS verifies and strips this information at its ASBRs. Packets that fail validation are dropped by the ASBR. RISAV achieves Source Address Validation among all participating ASes. "A solution to the Hierarchical Route Reflector issue in RT Constraints", MOHANTY Satya, Juan Alcaide, Mrinmoy Ghosh, 2023-11-09, Route Target Constraints (RTC) is used to build a VPN route distribution graph such that routers only receive VPN routes corresponding to specified route-targets (RT) that they are interested in. This is done by exchanging the route-targets as routes in the RTC address-family and a corresponding "RT filter" is installed that influences the VPN route advertisement. In networks employing hierarchical Route Reflectors (RR) the use of RTC can lead to incorrect VPN route distribution and loss in connectivity as detailed in an earlier draft . Two solutions were provided to overcome the problem. This draft presents a method with suggested modifications to the RTC RFC in order to solve the hierarchical RR RTC problem in an efficient manner. "UMR application in Ethernet VPN(EVPN)", Zheng Fu, Tong Zhu, Haibo Wang, Jian Dai, Dawei Wang, 2023-11-17, This document describes an application scenario that how unknown MAC- route(UMR) is used in the EVPN network. In particular, this document describes how MAC address route and UMR route are advertised on DC's GW or NVE. This document also describes the soloution that MAC mobility issue due to the lack of advertisement of specific MAC routes. However, some incremental work is required, which will be covered in a separate document. "dCBOR: A Deterministic CBOR Application Profile", Wolf McNally, Christopher Allen, Carsten Bormann, 2024-01-09, 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. "Deep Audio Redundancy (DRED) Extension for the Opus Codec", Jean-Marc Valin, Jan Buethe, 2024-02-23, This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. "A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)", Acee Lindem, Xufeng Liu, Athanasios Kyparlis, Ravi Parikh, Mingui Zhang, 2024-03-01, This document describes a 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. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document obsoletes RFC 8347. "IS-IS and OSPF extensions for TVR (Time-Variant Routing)", Zheng Zhang, Haisheng Wu, 2023-10-17, TVR needs IGP to calculate different results depending on the time, without convergence after the detection of link or nodes. IGP nodes need to learn the predictable and scheduled changes in advance. This document defines the IGP extensions for predictable and scheduled changes of TVR. "Simplified MVPN for BIER and IR", Fanghong Duan, Siyu Chen, 2024-03-04, Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution. "SR Policy for enhanced DetNet", Li Zhang, Xuesong Geng, Zhenbin Li, 2024-02-29, 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. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied. "The DNSCrypt protocol", Frank Denis, 2024-02-07, The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation. 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-dprive-dnscrypt/. Source for this draft and an issue tracker can be found at https://github.com/DNSCrypt/dnscrypt-protocol. "BGP extensions for BIER-TE", Ran Chen, BenChong Xu, Zheng Zhang, 2024-01-18, Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. 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 as described in [RFC8279]. This document describes BGP extensions for advertising the BIER-TE specific information. "Source IPv6 Address Programmability", Weiqiang Cheng, Liyan Gong, Changwang Lin, Hao Li, 2024-03-03, 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 "Segment Routing Header Extensions for DetNet Data Fields", Quan Xiong, Haisheng Wu, Dong Yang, 2023-10-13, The DetNet data fields defined in Deterministic Latency Action (DLA) can be used in enhanced Deterministic Networking (DetNet) to provide QoS treatment to achieve deterministic latency. This document defines how DetNet data fields are encapsulated as part of the Segment Routing with IPv6 data plane (SRv6) header. "IETF Meeting Venue Requirements Review", Jay Daley, Sean Turner, 2024-02-29, Following a review of the IETF meeting venue requirements, this document proposes updates to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and proposes a replacement exploratory meeting process, thereby updating RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF". "Post-Stack MPLS Network Action (MNA) Solution", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong, 2023-10-21, 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 draft- ietf-mpls-mna-hdr. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional OAM information in the MPLS packet or perform user-defined operations. This document addresses the MNA requirements specified in draft-ietf-mpls-mna- requirements. This document follows the MNA framework specified in draft-ietf-mpls-mna-fwk. "On the Effects of Internet Consolidation", Mark McFadden, Dominique Lazanski, 2023-10-20, This document contributes to the continuing discussion on Internet consolidation. Over the last several years there have been many types of discussions around consolidation at a technical level, an economic or market level and also at an engineering level. This document aims to discuss recent areas of Internet consolidation and provide some suggestions for advancing the discussion. "Extensible Simple Authentication and Security Layer (SASL)", Dave Cridland, Thilo Molitor, Matthew Wild, Alexey Melnikov, 2023-10-23, The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. "Applicability of Abstraction and Control", Gabriele Galimberti, Jean-Francois Bouquier, Ori Gerstel, Brent Foster, Daniele Ceccarelli, Sergio Belotti, Oscar de Dios, 2024-02-12, This document extends the I-D.draft-ietf-teas-actn-poi-applicability to the use case where the DWDM optical coherent interface is equipped on the Packet device. The document analyzes several control architectures and identifies the YANG data models being defined by the IETF to support this deployment architectures and specific scenarios relevant for Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. "EVPN Inter-Domain Option-B Solution", Jorge Rabadan, Senthil Sathappan, Ali Sajassi, Wen Lin, 2024-03-04, 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, 2024-03-04, This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service 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, 2023-10-23, 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. "BIER Flow Overlay with Anycast Egress Protection", Zhaohui Zhang, IJsbrand Wijnands, Zheng Zhang, Mankamana Mishra, Huaimo Chen, 2024-02-06, This document discusses considerations and specifies procedures for multicast flow overlay when BIER Anycast is used for egress protection in the context of MVPN and EVPN. Future revisions will cover other flow overlay protocols like PIM/MLD/mLDP. "SID as source address in SRv6", Feng Yang, Changwang Lin, 2024-01-18, 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. "MoQ relay for support of deadline-aware media transport", Yong Cui, Chuan Ma, Yixin Liao, Hang Shi, 2024-03-03, This draft specifies the behavior of MoQ relays for delivering media before the deadline to decrease end-to-end latency and save transport costs in media transmission. To achieve this, the draft introduces deadline-aware actions prioritizing media streams with earlier deadlines, ensuring timely transmission while minimizing costs. "SR-MPLS FRR Extension", Huaimo Chen, Zhibo Hu, Aijun Wang, Yisong Liu, Gyan Mishra, 2023-10-18, The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node on an SR-MPLS path by the neighbor upstream node as point of local repair (PLR) of the failed node. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbor upstream node of the failed node will no longer have a route to the failed node. This document describes a simple mechanism to extend the fast re-route protection for the failure on an SR-MPLS path after the IGP converges. The mechanism protects the node SID, adjacency SID and binding SID of the failed node on the path. "Security Considerations for Tenant ID and Similar Fields", Donald Eastlake, Nancy Cam-Winget, Mohammed Umair, 2023-10-12, 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. "A YANG Data Model for Optical Resource Performance Monitoring", Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, 2024-03-04, This document defines a YANG data model for performance Monitoring in optical networks which provides the functionalities of performance monitoring task management, TCA (Threshold Crossing Alert) configuration and current or historic performance data retrieval. This data model should be used in the northbound of PNC. "Considerations for SRv6 across Untrusted Domain", Changwang Lin, Ce Zhou, Mengxiao Chen, 2023-12-22, 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, 2023-10-18, 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. "Network Management Intent -One of IBN Use Cases", Danyang Chen, Kehan Yao, Chungang Yang, Xinru Mi, Ying Ouyang, 2024-03-03, Full life cycle network management will be a key feature of the future communication networks. Meanwhile, the complexity of the network management should be reduced and the network expects to be managed in a fully automated manner with humans out of the loop. In this document, we propose an use case of intent based network management to achieve more flexible , convenient, and efficient network management. In this use case, we propose an architecture and attempt to illustrate the five levels of achieving full autonomous network management. "Selective Synchronization for RPKI to Router Protocol", Nan Geng, Shunwan Zhuang, Mingqing(Michael) Huang, 2024-03-03, 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. "Design analysis of methods for distributing the computing metric", Hang Shi, Zongpeng Du, Xinxin Yi, Tianle Yang, 2024-03-01, 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. "BMP Loc-RIB: Peer address", Pierre Francois, Maxence Younsi, Paolo Lucente, 2024-03-04, BMP Loc-RIB lets a BMP publisher set 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. "Structured Connection ID Carrying Metadata", Hang Shi, 2024-03-04, This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization. "BGP Extensions for Source Address Validation Networks (BGP SAVNET)", Nan Geng, Zhenbin Li, Zhen Tan, Mingxing Liu, Dan Li, Fang Gao, 2023-11-22, Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. "IGP Extensions for Link MTU", Zhibo Hu, Shuping Peng, Xing Xi, 2024-01-27, Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths which are called segments. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS and OSPF extensions about the Path MTU that need to be used on SR. Here, the term "OSPF" means both OSPFv2 and OSPFv3. "IP Addressing Considerations", Luigi Iannone, 2023-10-23, The Internet Protocol (IP) has been the major technological success in information technology of the last half century. As the Internet becomes pervasive, IP has been replacing communication technology for many domain-specific solutions, but it also has been extended to better fit the specificities of the different use cases. For Internet addressing in particular, as it is defined in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively, there exist many extensions. Those extensions have been developed to evolve the addressing capabilities beyond the basic properties of Internet addressing. This document discusses the properties the IP addressing model, showcasing the continuing need to extend it and the methods used for doing so. "One Administrative Domain using BGP", Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen, 2024-01-10, 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). "IS-IS Extension for Big TLV", Huaimo Chen, Bruno Decraene, Gyan Mishra, Aijun Wang, Zhenqiang Li, Yanhe Fan, Xufeng Liu, Lei Liu, Donald Eastlake, 2023-11-21, 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 backward compatible IS-IS extension for encoding the TLV whose value is bigger than 255 octets. "Realization of Composite IETF Network Slices", Zhenbin Li, Jie Dong, Ran Pang, Yongqing Zhu, Luis Contreras, 2024-03-04, 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 XXXX 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 XXXX. 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. "The Proximate Location Claim", Giridhar Mandyam, 2024-01-17, The Entity Attestation Token (EAT) is an extensible attestation version of a CBOR Web Token (CWT). EAT defines a location claim, but does not define a proximate location claim. This document proposes a claim in which an attester can relay detected relative location of a target. "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, 2024-03-04, This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios, for end-to-end customer L2VPN or L3VPN connectivity services setup over underlying transport optical paths, with specific Service Level Agreement (SLA) requirements. EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. 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. "Using Deterministic Networks for Industrial Operations and Control", Kiran Makhijani, Richard LI, Cedric Westphal, Luis Contreras, Tooba Faisal, 2023-09-26, Remote industrial processes enable control & operations from the software-defined application logic. In order to support process automation remotely, not only Deterministic Networks (DetNet) are needed but an interface between the application endpoints to the devices over a DetNet infrastructure is also required. This document describes an interface to deterministic networks from the view of endpoints to support process control and operations. "Auto Edge Protection", Shraddha Hegde, Krzysztof Szarkowicz, Zhaohui Zhang, Bruno Decraene, Dan Voyer, Luay Jalil, 2024-02-09, This document specifies procedures to automatically establish context based forwarding for providing fast reroute during egress node and egress link failures. It describes how to detect multi-homed services and establish context for forwarding. It also defines procedures to avoid conflicts among routers while establishing context. "Partially Blind RSA Signatures", Ghous Amjad, Scott Hendrickson, Christopher Wood, Kevin Yeo, 2024-01-10, 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. "EVPN First Hop Security", Ali Sajassi, Lukas Krattiger, Krishnaswamy Ananthamurthy, Jorge Rabadan, Wen Lin, 2024-02-22, The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures for Ethernet VPN (EVPN) will distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi-homing. "The MASQUE Proxy", David Schinazi, 2024-02-28, 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. "Sustainability Insights", Per Andersson, Jan Lindblad, Snezana Mitrovic, Marisol Palmero, Esther Roure, Gonzalo Salgueiro, Stephan Emile, 2023-10-20, This document motivates the collection and aggregation of sustainability environmental related metrics. It describes the motivation and requirements to collect asset centric metrics including but not limited to power consumption and energy efficiency, circular economy properties, and more general metrics useful in environmental impact analysis. It provides foundations for building an industry-wide, open-source framework for the reduction of greenhouse gas emissions, enabling measurement and optimization of the overall impact on the environment of networking devices, software applications, services, and solutions across the lifecycle journey. "Low Overhead Media Container", Mo Zanaty, Suhas Nandakumar, Peter Thatcher, 2024-03-04, This specification describes a media container format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC transport (MOQ), with the goal of it being a low-overhead format. It also 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. "Emergency Communication Services over Wi-Fi Access Networks", Sri Gundavelli, Mark Grayson, 2024-01-11, This document introduces an approach to enable emergency services over Wi-Fi access networks. These services encompass emergency services such as 911 in North America, 112 in the European Union, and equivalent emergency services in other regulatory domains. The proposed approach aims to provide a comprehensive solution for supporting emergency communication across different regions and regulatory frameworks. Leveraging the legal framework and infrastructure of the OpenRoaming federation, this proposal aims to extend emergency calling capabilities to the vast number of OpenRoaming Wi-Fi hotspots that have already been deployed. The approach addresses critical challenges related to emergency calling, including discovery and authentication procedures for accessing networks that support emergency services, emergency access credentials, the configuration of emergency voice services, accurate location determination of the emergency caller, and call spofing. By providing a comprehensive solution, this proposal ensures that emergency communication services can be seamlessly and effectively supported within the IEEE 802.11-based Wi-Fi ecosystem leveraging Passpoint Profiles. "Linearized Matrix", Travis Ralston, Matthew Hodgson, 2024-01-10, This document specifies Linearized Matrix (LM). LM is an extensible protocol for interoperability between messaging providers, using Matrix's (matrix.org (https://matrix.org)) decentralized room model. LM simplifies the Directed Acyclic Graph (DAG) persistence of Matrix while maintaining compatibility with non-linearized servers within a room. It does this by using a doubly-linked list of events/messages per room with hub and spoke fanout. LM's extensibility enables a wide range of transport protocol and end-to-end encryption possibilities. This document uses Matrix's room access control semantics supported by Messaging Layer Security (MLS), transported via HTTPS and JSON. The details of which server- to-server transport to use and what is put over MLS are replaceable. The threat model of LM does not place trust in a central owning server for each conversation. Instead, it defines a hub server which handles maintaining linearized room history for other servers in the room. This model permits transparent interconnection between LM servers and Matrix servers, in the same room. "Trusted Domain SRv6", Andrew Alston, Tom Hill, Tony Przygienda, Luay Jalil, 2023-10-08, SRv6 as designed has evoked interest from various parties, though its deployment is being limited, amongst other things, by known security problems in its architecture. This document specifies a standard way to create a solution that closes some of the major security concerns, while retaining the tenants of the SRv6 protocol. "Delegated Credentials to Host Encrypted DNS Forwarders on CPEs", Tirumaleswar Reddy.K, Mohamed Boucadair, Dan Wing, Shashank Jain, 2023-12-01, An encrypted DNS server is authenticated by a certificate signed by a Certificate Authority (CA). However, for typical encrypted DNS server deployments on Customer Premise Equipment (CPEs), the signature cannot be obtained or requires excessive interactions with a Certificate Authority. This document explores the use of TLS delegated credentials for a DNS server deployed on a CPE. This approach is meant to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility", Christian Amsuess, 2023-10-21, 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. "Policy experts are IETF stakeholders", Stacie Hoffmann, Marek Blachut, 2024-01-10, The IETF's work has significance for communities concerned with societal, economic, and political outcomes, though barriers to engagement with the IETF exist for non-technical experts from these communities. This informational document introduces a problem statement and gap analysis of existing initiatives related to policy expert engagement in the IETF. It aims to be a resource for anyone interested in working to enable policy expert engagement in IETF standardisation. "Content Delivery Network Interconnection (CDNI) Named Footprints", Alan Arolovitch, 2024-03-04, 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. "X25519Kyber768Draft00 hybrid post-quantum key agreement", Bas Westerbaan, Douglas Stebila, 2023-09-24, This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3. "Aircraft to Anything AdHoc Broadcasts and Session", Robert Moskowitz, Stuart Card, Andrei Gurtov, 2023-10-23, Aircraft-to-anything (A2X) communications are often single broadcast messages that 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 a lower cost symmetric key protect flow can be used. This document shows both how to secure A2X broadcast messages with DRIP DET and Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for using X.509 certificates, encoded in c509, as an alternative DET trust model. "Applying Per-Session Limits for WebTransport", Martin Thomson, Eric Kinnear, 2023-10-10, Limits to how a WebTransport session uses QUIC resources like streams or data can help reduce the effect that one WebTransport session has on other uses of the same HTTP/3 connection. This describes mechanisms for limiting the number of streams and quantity of data that can be consumed by each WebTransport session. "Efficient Air-Ground Communications", Robert Moskowitz, Stuart Card, Andrei Gurtov, 2023-09-28, This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to ground-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) to address both reliable wireless packet delivery, and assured terrestrial packet delivery. "Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries", Jesse Carter, Jacques Latour, Mathieu Glaude, 2023-10-10, This memo describes an architecture for digital credential verification and validation using Decentralized Identifiers (DIDs), distributed ledgers, trust registries, and the DNS. This architecture provides a verifier with a simple process by which to cryptographically verify the credential they are being presented with, verify and resolve the issuer of that credential to a domain, and verify that issuer's membership in a trust registry. "Green Challenges in Computing-Aware Traffic Steering (CATS)", Jing Wang, Yuexia Fu, Cheng Li, 2024-03-04, 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, 2024-03-17, 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. "Improved OSPF Database Exchange Procedure", Shraddha Hegde, Tony Przygienda, Acee Lindem, 2023-10-16, When an OSPF router undergoes restart, previous instances of LSAs belonging to that router may remain in the databases of other routers in the OSPF domain until such LSAs are aged out. Hence, when the restarting router joins the network again, neighboring routers re- establish adjacencies while the restarting router is still bringing- up its interfaces and adjacencies and generates LSAs with sequence numbers that may be lower than the stale LSAs. Such stale LSAs may be interpreted as bi-directional connectivity before the initial database exchanges are finished and genuine bi-directional LSA connectivity exists. Such incorrect interpretation may lead to, among other things, transient traffic packet drops. This document suggests improvements in the OSPF database exchange process to prevent such problems due to stale LSA utilization. The solution does not preclude changes in the existing standard but presents an extension that will prevent this scenario. "MIMI Terminology", Travis Ralston, 2023-10-23, This document introduces a set of terminology to use when discussing or describing concepts within MIMI. "Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS", Gilles Lehmann, 2023-10-12, 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. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. "LISP Multicast Overlay Group to Underlay RLOC Mappings", Vengada Govindan, Dino Farinacci, Aswin Kuppusami, Stig Venaas, 2023-10-16, This draft augments LISP [RFC9300] multicast functionality described in [RFC6831] and [RFC8378] 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. "BFD Path Consistency over SR", Changwang Lin, Weiqiang Cheng, Jiang Wenying, Ran Chen, 2023-11-08, 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, 2023-10-09, 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. "Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger, 2024-02-19, The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in [RFC7387], "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of [RFC7796], "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by [RFC7385]; hence, it updates [RFC7385] accordingly. This document obsoletes [RFC8317]. "Detecting Unwanted Location Trackers", Brent Ledvina, Zachary Eddinger, Ben Detwiler, Siddika Polatkan, 2023-12-20, 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. "Purge Originator Identification for OSPF", Zhenqiang Li, Changwang Lin, 2023-11-08, 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. "QUIC-enabled Service Differentiation for Traffic Engineering", Zhilong Zheng, Yunfei Ma, Yanmei Liu, Mirja Kuehlewind, 2023-11-08, This document defines a method for supporting QUIC-enabled service differentiation for traffic engineering through multipath and QUIC connection identifier (CID) encoding. This approach enables end-host networking stacks and applications to select packet routing paths in a wide area network (WAN), potentially improving end-to-end performance, cost, and reliability. The proposed method can be used in conjunction with segment-routing traffic engineering technologies, such as SRv6 TE. "Galois Counter Mode with Secure Short Tags (GCM-SST)", Matt Campagna, Alexander Maximov, John Mattsson, 2024-03-16, This document defines the Galois Counter Mode with Secure Short Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm. GCM-SST can be used with any keystream generator, not just a block cipher. The main differences compared to GCM [GCM] is that GCM-SST uses an additional subkey Q, that fresh subkeys H and Q are derived for each nonce, and that the POLYVAL function from AES- GCM-SIV is used instead of GHASH. This enables short tags with forgery probabilities close to ideal. This document also registers several instances of Advanced Encryption Standard (AES) with Galois Counter Mode with Secure Short Tags (AES-GCM-SST). This document is the product of the Crypto Forum Research Group. "Enforcing end-to-end delay bounds via queue resizing", Antoine Fressancourt, 2023-11-07, 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. "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, 2023-09-19, This document describe a widely deployed hybrid key exchange methods in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Boris Makarenko, Vasily Dolmatov, 2024-01-25, This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). "Hybrid X25519 and Streamlined NTRU Prime sntrup761 with SHA3-256: Chempat-X", Simon Josefsson, 2024-01-20, This memo define Chempat-X, a post-quantum/traditional hybrid key exchange method (PQ/T KEM) based on X25519 and Streamlined NTRU Prime sntrup761 with SHA3-256. "TLS 1.2 is in Feature Freeze", Rich Salz, Nimrod Aviram, 2023-10-05, TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, no new features will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. "WebSocket Extension to disable masking", Dragana Damjanovic, 2024-02-27, The WebSocket protocol specifies that all frames sent from the client to the server must be masked. This was introduced as a protection against a possible attack on the infrastructure. With careful consideration, the masking could be omitted when intermediaries do not have access to the unencrypted traffic. This specification introduces a WebSocket extension that disables the mandatory masking of frames sent from the client to the server. The extension is allowed only if the client uses an encrypted connection. "Extensible Provisioning Protocol (EPP) Transport over QUIC", Jiankang Yao, Hongtao Li, Zhiwei Yan, Dan Keathley, James Gould, 2024-02-18, 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. "Cycle Mapping Learning Method for Scaling DetNet", Xiangyang Zhu, Yu jinghai, Chenqiang Gao, Quan Xiong, 2023-12-26, The scaling DetNet (Deterministic Networking) technology based on cyclic queuing and scheduling is expected to solve the scalability problem of DetNet, and is hoped to extend the adaptive domain of DetNet to wide area network or even backbone network. One of the keys of this technology is to accurately obtain the cyclic mapping relationship between adjacent nodes, based on which DetNet packets can be end-to-end deterministically forwarded . This draft proposes a method for nodes to learn the cycle mapping relationship through sending learning messages. "S-Expressions", Ronald Rivest, Donald Eastlake, 2024-03-18, This memo describes a data structure called "S-expressions" that are suitable for representing arbitrary, complex data structures. We make precise the encodings of S-expressions: we give a "canonical form" for S-expressions, described two "transport" representations, and also describe an "advanced" format for display to people. "A SAVI Solution for WLAN", Mingwei Xu, Jianping Wu, Tao Lin, Lin He, You Wang, 2024-01-10, 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. "An Emulation System Architecture for Space Network", Kanglian Zhao, Hou Dongxu, Xiao Min, 2024-02-17, This document describes an emulation architecture which provides a realistic, flexible, and extensible experimental environment for the space network (SN). The architecture includes four components, namely logical plane, control plane, data plane and measurement plane. Software-defined networking (SDN), virtualization technology, and traffic control mechanism are adopted to realize the real space environment and arbitrary topology. Furthermore, an extensible structure is described to emulate large-scale scenarios and access external emulation resources. "Security Profiles in Bootstrap Voucher Artifacts", Jabir Mohammed, Reda Haddad, Srihari Raghavan, Sandesh Rao, 2023-11-27, This document describes an extension of the RFC8366 Voucher Artifact in order to support security profiles. This allows the owner to change and customize the security posture of the device dynamically and securely. This lets the owner to selectively enable or disable each of the underlying security parameters that make up the security posture of the device. "A Mechanism for Encoding Differences in Paired Certificates", Corey Bonnell, John Gray, D. Hook, Tomofumi Okubo, Mike Ounsworth, 2024-01-04, 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 construct the paired certificate and perform certification path validation using the constructed 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. "Multi-segment SD-WAN via Cloud DCs", Kausik Majumdar, Linda Dunbar, Venkit Kasiviswanathan, Ashok Ramchandra, Aseem Choudhary, 2024-02-20, This document describes a method for SD-WAN CPEs using GENEVE Encapsulation (RFC8926) to encapsulate the IPsec encrypted packets and send them to their closest Cloud GWs, who can steer the IPsec encrypted payload through the Cloud Backbone without decryption to the egress Cloud GWs which then forward the original IPsec encrypted payload to the destination CPEs. This method is for Cloud Backbone to connect multiple segments of SD-WAN without the Cloud GWs decrypting and re- encrypting the payloads. "RPKI Publication Server Best Current Practices", Tim Bruijnzeels, Ties de Kock, Frank Hill, Tom Harrison, 2024-01-18, 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. "Generating the Transport Key Containers Using the GOST Algorithms", Karelina Ekaterina, 2023-12-12, This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to generate the transport key containers for storing keys and certificates in conjunction with the Russian national standard GOST algorithms. This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here. "Signaling In-Network Computing operations (SINC)", Zhe Lou, Luigi Iannone, Yizhou Li, Zhangcuimin, Kehan Yao, 2024-03-16, 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. "Signaling In-Network Computing operations (SINC) deployment considerations", Zhe Lou, Luigi Iannone, Yizhou Li, Zhangcuimin, 2023-12-08, This document is intended to discuss some deployment aspects of "Signaling In-Network Computing operations" (SINC). Based on some examples, this document analyzes how each device in the SINC chain undertakes its own functions. This document showcase the use of SINC mechanism. "WARP Streaming Format", Will Law, Luke Curley, Victor Vasiliev, Suhas Nandakumar, Kirill Pugin, 2024-01-22, This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. "Jitter Reduction Mechanism for DetNet", Daorong Guo, Shenchao Xu, 2023-10-23, In large-scale deterministic networks (LDN), App-flows need to span multiple deterministic network domains, and the latency in multiple domains is added together. The jitter will be increased. In order to realize the protection service function, App-flows should be transmitted on multiple paths. The delay difference in data transmission on different paths is no different from jitter in end- to-end services. Jitter generated by various factors needs to be controlled to meet business requirements. This document describes the end-to-end jitter reduction mechanism in an LDN. This mechanism can effectively control the end-to-end jitter to meet specific business needs and make the planning of multiple paths for service protection more flexible. "An Overview of Network Slicing Efforts in The IETF", Mohamed Boucadair, 2024-02-15, 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. "Analysis and Evaluation for TSN Queuing Mechanisms", Jinjie Yan, Yufang Han, Shaofu Peng, Yuehong Gao, 2023-12-20, TSN technology standards developed in the IEEE 802.1TSN Task Group define the time-sensitive mechanism to provide deterministic connectivity through IEEE 802 networks, i.e., guaranteed packet transport with bounded latency, low packet delay variation, and low packet loss.This document summarizes and evaluates various queuing technologies of TSN as reference information for Scaling Deterministic Networks Requirements[I-D.ietf-detnet-scaling-requirements] and Enhancing Deterministic Forwarding. "SRv6 Context Indicator SIDs for SR-Aware Services", Changwang Lin, Dongjie Lu, Mengxiao Chen, Meiling Chen, 2023-12-20, 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, 2024-02-16, 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. "Green Networking Metrics", Alexander Clemm, Lijun Dong, Greg Mirsky, Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini, Eve Schooler, Ali Rezaki, Carlos Pignataro, 2024-03-04, This document explains the need for network instrumentation that allows to assess a number of sustainability-related attributes such as power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's "greenness" accordingly. "Routing Framework for LEO Mega-constellation Based on Region Division", Hou Dongxu, Xiao Min, Fenlin Zhou, 2024-02-17, The inter-satellite routing is the premis to ensure that the satellite network provides end-to-end stable service covering the whole globe. However, the mature terrestrial network technologies are difficult to directly apply to the satellite network because of the highly dynamic network topology and the limited on-board resources. This issue is further exacerbated in LEO mega- constellations. In view of this challenge, this document presents a routing framework for LEO mega-constellation. Based on the orbit position characteristic and the predictable topology, this framwork realizes flexible region division, establishes intra-region and inter-region path, as well as completes end-to-end data forwarding. "RIFT extensions for SRv6", Weiqiang Cheng, Changwang Lin, Ruixue Wang, 2024-03-04, The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topologicalelements 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). "The Monitoring Plugins Interface", Lorenz Kaestle, 2023-09-24, This document aims to document the Monitoring Plugin Interface, a standard more or less strictly implemented by different network monitoring solutions. Implementers and Users of network monitoring solutions, monitoring plugins and libraries can use this as a reference point as to how these programs interface with each other. "PIM Flooding Mechanism Enhancements", Ananya Gopal, Stig Venaas, 2024-03-04, PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows Last Hop Routers to learn about new sources using PFM messages, without the need of initial data registers, RPs or shared trees. This document defines a methodology that enhances forwarding efficiency in PFM deployments. This enhancement can avoid extra processing at PIM routers when PFM messages are forwarded. "Simple Random Candidate Selection", Paul Hoffman, 2023-11-20, This document describes a process to randomly select a subset of named candidates from a larger set of candidates. The process uses an unpredictable value that can be trusted by all candidates. This draft has a GitHub repository (https://github.com/paulehoffman/ draft-hoffman-random-candidate-selection). Issues and pull requests can be made there. "Intel Profile for CoRIM", James Beaney, Andrew Draper, Vincent Scarlata, Ned Smith, 2023-12-20, This document describes extensions to the CoRIM schema that support Intel specific Attester implementations. Multiple Evidence formats are compatible with base CoRIM, but extensions to evidence formats may be required to fully support the CoMID schema extensions defined in this profile. The concise evidence definition uses the CoMID schema such that extensions to CoMID are inherited by concise evidence. Reference Value Providers may use this profile to author mainifests containing Reference Values and Endorsements. RATS Verifiers recognize this profile by it's profile identifier and implement support for the extentions defined. "Latency Guarantee with Stateless Fair Queuing", Jinoo Joung, Jeong-dong Ryoo, Taesik Cheung, Yizhou Li, Peng Liu, 2024-02-29, This document specifies the framework and the operational procedure for deterministic networking with work conserving packet schedulers that guarantee end-to-end latency bounds to flows. Schedulers in core nodes of the network do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding a delay factor, which is a function of the flow and upstream nodes. The packets in the queue are served in the ascending order of the FT. This technique is called Fair Queuing (FQ). 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, except the link capacities and the maximum packet lengths among other flows sharing each output link with the flow. "Framework for Rule-based International Cyberspace Governance", Han Liu, Jilong Wang, Chengyuan Zhang, Pardis Tehrani, Ji Ma, 2023-12-30, Cyberspace involves politics, economy, culture, and technology; it engages governments, international organizations, Internet companies, technology communities, civil society, and citizens, forming an integrated, organic body. In a word, cyberspace is the online version of a community with a shared future for mankind. This memo tries to outline a new framework for rule-based international cyberspace governance regime in the context of IPv6 application, which looks into the future international cooperation of cyberspace governance. "SCION Control Plane", Corine de Kater, Nicola Rustignoli, Samuel Hitz, 2024-03-04, This document describes the control 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 SCION- capable endpoints. In fact, endpoints can choose between multiple path options, enabling the optimization of network paths. The SCION control plane is responsible for discovering these paths and making them available to the endpoints. The main goal of SCION's control plane is to create and manage path segments, which can then be combined into forwarding paths to transmit packets in the data plane. This document first discusses how path exploration is realized through beaconing and how path segments are created and registered. Each SCION autonomous system (AS) can register segments according to its own policy - it is free to specify which path properties and algorithm(s) to use in the selection procedure. The document then describes the path lookup process, where endpoints obtain path segments - a fundamental building block for the construction of end-to-end paths. "Performance Measurement with Asymmetrical Packets in STAMP", Greg Mirsky, Ernesto Ruffini, Henrik Nydell, Richard Foote, 2024-02-20, This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length 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. "OAM for LPWAN using Static Context Header Compression (SCHC)", Dominique Barthel, Laurent Toutain, 2024-01-19, This document describes how SCHC can be used to efficiently perform basic Operation, Administration and Maintenance (OAM) on Low Power Wide Area Networks (LPWANs) by compressing ICMPv6/IPv6 headers, or by shielding the LPWAN network and the Device from undesirable ICMPv6 traffic. This document specifies additional behavior for SCHC [RFC8724] and extends the YANG Data Model defined in [RFC9363]. "Communicating Proxy Configurations in Provisioning Domains", Tommy Pauly, Dragana Damjanovic, 2024-03-01, 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. "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, 2024-01-05, 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. "SRv6 Segment List optimization", Yisong Liu, Changwang Lin, Ran Chen, Yuanxiang Qiu, 2024-01-05, This document introduces an optimization method for segment list arrangement to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. "Inter-domain Source Address Validation based on AS relationships", Ren Gang, Shuqi Liu, Xia Yin, 2023-10-23, This draft introduces an inter-domain source address validation scheme based on relationships between interconnected ASes. This scheme is mainly described from four aspects, namely the research background in fields of source address validation and AS relationships, introduction to the classification and acquisition methods of AS relationships, the specific architecture of our inter- domain source address validation system based on AS relationships, and the considerations on deployability. "Sloppy Topology Updates for ad-hoc Routing Protocols (STURP)", Zhe Lou, Luigi Iannone, Dirk Trossen, Zhaochen Shi, 2023-12-30, This memo describes an approach to updating topologies in typical MANET-like environments, relying on what is termed 'sloppy updates' in the remainder of this document. Key to the approach is that updates are only initiated if existing communication relations may be effect by non-synchronized topology information, otherwise using the topology information as it exists. This 'sloppy' nature of the approach reduces the needed updates and the associated communication for them, thus increases efficiency as well as performance from a user perspective. "PIM Flooding Mechanism and Source Discovery Sub-TLV", Stig Venaas, Francesco Meo, 2024-03-04, PIM Flooding Mechanism and Source Discovery (RFC 8364) allows for announcement of active sources, but it does not allow for providing additional information about the flow. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document defines a Sub-TLV for flow data rate. "Update to Automatic Bandwidth Adjustment procedure of Stateful PCE", Shuping Peng, Dhruv Dhody, Rakesh Gandhi, 2023-12-25, 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. But it lacks a mechanism to explicitly remove an attribute identified by the sub- TLV. This document updates RFC 8733 by defining the behaviour to explicitly remove an attribute.. "Guidelines for Internet Congestion Control at Endpoints", Gorry Fairhurst, Michael Welzl, 2023-10-23, When published as an RFC, this document provides guidance on the design of methods to avoid congestion collapse and how an endpoint needs to react to congestion. Based on these, and Internet engineering experience, the document provides best current practice for the design of new congestion control methods in Internet protocols. When published, the document will update or replace the Best Current Practice in BCP 41, which currently includes "Congestion Control Principles" provided in RFC2914. "Bundle Protocol Yang Model", Marc Blanchet, Yingzhen Qu, 2024-03-04, This document describes the Yang model for the Bundle protocol. "Hybrid key exchange in JOSE and COSE", Tirumaleswar Reddy.K, Aritra Banerjee, 2023-10-20, 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 JOSE and COSE. It defines the use of traditional and PQC algorithms, a hybrid post-quantum KEM, for JOSE and COSE. "HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman, 2024-02-29, 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, 2024-02-29, 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. "Problem statements and requirements of L2 CATS", Daniel Huang, Bin Tan, 2024-01-05, The computing intensive parts of the customer premise equipment have been decoupled and migrated to the cloud, therefore the thin CPE remaining at customer premise needs to access its “avatar” virtual CPE in the cloud which could be deployed in multiple edge computing sites. This draft will illustrate a use case of L2 traffic steering in terms of dynamic computing and networking resource status, together with requirements for CATS as well as solution consideration with regard to particularly the difference from the L3 routing framework. "Routing mechanism in Dragonfly Networks Gap Analysis, Problem Statement, and Requirements", Ruixue Wang, Changwang Lin, wangwenxuan, Weiqiang Cheng, 2024-03-03, 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, 2024-01-04, 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. "PCEP Extension to Support SRv6 Segment List optimization", Changwang Lin, Yisong Liu, Ran Chen, Yuanxiang Qiu, 2024-01-05, 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 optimizing the arrangement of segment lists to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. "Auto-discovery mechanism for ACME servers", Paul van Brouwershaven, Mike Ounsworth, Corey Bonnell, Inigo Barreira, Q Misell, 2024-02-15, A significant impediment to the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is that ACME clients need to be pre-configured with the URL of the ACME server to be used. This often leaves domain owners at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used. This specification provides a mechanism to bootstrap ACME client configuration from a domain's DNS CAA Resource Record [RFC8659], thus giving control of which CA(s) to use back to the domain owner. Specifically, this document specifies two new extensions to the DNS CAA Resource Record: the "discovery" and "priority" parameters. Additionally, it registers the URI "/.well-known/acme" at which all compliant ACME servers will host their ACME directory object. By retrieving instructions for the ACME client from the authorized CA(s), this mechanism allows for the domain owner to configure multiple CAs in either load-balanced or fallback prioritizations which improves user preferences and increases diversity in certificate issuers. "Raytime: Validating token expiry on an unbounded local time interval", Christian Amsuess, 2024-01-11, When devices are deployed in locations with no real-time access to the Internet, obtaining a trusted time for validation of time limited tokens and certificates is sometimes not possible. This document explores the options for deployments in which the trade-off between availability and security needs to be made in favor of availability. While considerations are general, terminology and examples primarily focus on the ACE framework. "Multiple Algorithm Rules in DNSSEC", Shumon Huque, Peter Thomassen, Viktor Dukhovni, Duane Wessels, 2023-11-07, 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. "Extension Header Use Cases", Mike McBride, Nalini Elkins, Nick Buraglio, Xuesong Geng, michael ackermann, 2024-02-26, This document outlines IPv6 extension header use cases including those intended to be deployed in limited domains and those intended for the global Internet. We specify use cases are deployed today and those which may be of use in the future. The hope is that through understanding these various extension header use cases, we can then better understand how best to improve upon extension header deployments including any limits on their use. "Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism", Rafael Belchior, Miguel Correia, Andre Augusto, Thomas Hardjono, 2024-01-29, 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). "Computing and Network Information Awareness (CNIA) system architecture for CATS", Huijuan Yao, xuewei wang, Zhiqiang Li, Daniel Huang, Changwang Lin, 2023-10-22, This document describes a Computing and Network Information Awareness (CNIA)system architecture for Computing-Aware Traffic Steering (CATS). Based on the CATS framework, this document further describes a proposal detailed awareness architecture about the network information and computing information. It includes a new component and the corresponding interfaces and workflows in the CATS control plane. "Use of Reliable Transport in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2023-12-28, The Internet Key Exchange protocol version 2 (IKE2) 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 which arise when TCP is used for IPsec. "Problem Statement and Requirements of end-to-end CATS", Dongyu Yuan, Huijuan Yao, Zhiqiang Li, Fenlin Zhou, xuewei wang, 2023-10-22, This document describes and proposes problem statement and incremental requirements of an end-to-end computing aware traffic steering (CATS) process illustrated in [I-D.ldbc-cats-framework]. Particularly, this document analyzes the significance of appropriate aggregation algorithms and the necessity of hierarchical forwarding mechanisms. "Middle Ware Facilities for CATS", Dongyu Yuan, Fenlin Zhou, 2024-01-02, This draft proposes a method to perceive and process the running status of computing resources by introducing a logical Middle Ware facility, aiming to avoid directly reflecting continuous and dynamic computing resource status in the network domain, match service requirements and instance conditions, and ultimately achieve computing aware traffic steering and be applicable to various possible scheduling strategies. "Validity of SR Policy Candidate Path", Ran Chen, Yisong Liu, Ketan Talaulikar, Samuel Sidor, Detao Zhao, Changwang Lin, Zafar Ali, 2024-03-01, 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. "Microloop Prevention in a Hierarchical Segment Routing Solution for CATS", Dongyu Yuan, Fenlin Zhou, 2024-01-02, Considering computing and networking is quite different in terms of resource granularity as well as their status stability, a hierarchical segment routing is proposed and introduced as an end-to- end CATS process. However, it brings about potential problems as illustrated in [I-D.yuan-cats-end-to-end-problem-requirement]. In order to solve the mentioned problems and to improve and perfect a hierarchical solution, corresponding aggregation methods are discussed and hierarchical entries are proposed in this draft. "Validity of SR Policy Candidate Path", Ran Chen, Detao Zhao, Ketan Talaulikar, Yisong Liu, Changwang Lin, 2024-03-01, 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, Fang Gao, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng, 2024-03-03, 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. "Persistent Symmetric Keys in OpenPGP", Daniel Huigens, 2024-01-03, This document defines new algorithms for the OpenPGP standard (RFC4880) 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. "Views and View Addresses for Secure Asset Transfer", Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Krishnasuri Narayanam, 2024-01-08, 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, 2024-01-08, 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. "Integration of Speech Codec Enhancement Methods into the Opus Codec", Jan Buethe, Jean-Marc Valin, 2023-10-23, This document proposes a method for integrating a speech codec enhancement method into the Opus codec [RFC6716] "Deterministic Networking (DetNet) Data Plane - Flow interleaving for scaling detnet data planes with minimal end-to-end latency and large number of flows.", Toerless Eckert, 2024-01-05, This memo explain requirements, benefits and feasibility of a new DetNet service function tentatively called "flow interleaving". It proposes to introduce this service function into the DetNet architecture. Flow interleaving can be understood as a DetNet equivalent of the IEEE TSN timed gates. Its primary role is intended to be at the ingress edge of DetNet domains supporting higher utilization and lower bounded latency for flow aggregation (interleaving of flows into a single flow), as well as higher utilization and lower bounded latency for interleaving occurring in transit hops of the DetNet domain in conjunction with in-time per-hop bounded latency forwarding mechanisms. "Transaction Tokens", Atul Tulshibagwale, George Fletcher, Pieter Kasselman, 2023-10-20, 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 optionally immutably assert to downstream workloads that they were invoked in the call chain of the request. "Integrating the Alternate-Marking Method into In Situ Operations, Administration, and Maintenance (IOAM)", Xiaoming He, Frank Brockners, Haoyu Song, Giuseppe Fioccola, Aijun Wang, 2024-01-08, 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. "An SR-TE based Solution For Computing-Aware Traffic Steering", FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, 2024-01-07, 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, Henk Birkholz, 2024-03-01, 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. "DetNet YANG Model Extension for 5GS as a Logical DetNet Node", Tianji Jiang, Peng Liu, Xuesong Geng, 2023-10-20, The 3GPP Rel-18 has completed the working item (WID) of the DetNet, i.e., the Deterministic Network. This WID defines and standardizes how a 5G system (5GS) may behave as a logical DetNet transit node, as well as how a 5GS DetNet node may integrate into the IP deterministic network domain. A 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers. While the 3GPP work has referenced the IETF Detnet YANG model draft for the purpose of provisioning the DetNet traffic parameters to a 5GS logical DetNet node, the per-(logical)-node parameter provisioning needs to be further improved. This draft defines some new DetNet YANG parameters, e.g., the type of a (composite) DetNet node, the composite node ID, and the flow direction within a composite (5GS logical) node, via reusing the existing IETF DetNet YANG model. Toward the end, we also discuss some complicated 5GS related DetNet scenarios that would be considered for future extensions. "BGP Attribute Escape", Jeffrey Haas, 2024-02-02, 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 Digital Twin Network Performance Modeling", Mei Li, Cheng Zhou, Danyang Chen, 2023-10-19, Digital Twin Network (DTN) 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 DTN 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. "ANUP Implementation in 5G with BGP Signaling", Zhaohui Zhang, Keyur Patel, 2024-02-06, Draft-zzhang-dmm-mup-evolution describes an architecture in which co- located Access Node and User Plane Function node of a 5G mobile network are integrated into a single Network Function ANUP in 6G for simplified signaling and optimized forwarding. The integration can happen in 5G as well but only with optimized forwarding. This document describes how BGP signaling specified in Draft-mpmz-bess- mup-safi can be used for ANUP implementation in 5G. "Distributed architecture for microservices communication based on Information-Centric Networking (ICN)", Xueting Li, Aijun Wang, Wei Wang, Dirk Kutscher, Yue Wang, 2023-10-17, This draft defines a new communication architecture, called Distributed Architecture for Microservices Communication (DAMC). 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. The purpose of this draft is to combine the Information-Centric Networking (ICN) concept to enhance the overall performance, scalability and reliability of microservices communication. The DAMC architecture provides a powerful framework for managing the complex communication requirements of distributed microservices, ensuring integrity, security and efficient resource utilization. "BGP SR Policy Extensions for Path Scheduling", Li Zhang, Tianran Zhou, Jie Dong, Minxue Wang, Nkosinathi Nzima, 2023-10-22, Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths. This document proposes extensions to BGP SR Policy to indicate the enable time and disable time for routing paths to enable path scheduling. "Confidential Virtual Machine Provisioning in Cloud Environment", Deng, Guorui Yu, 2023-12-01, This document specifies the procedures of provisioning confidential virtual machine in the cloud environment. "Reverse HTTP Transport", Benjamin Schwartz, Tirumaleswar Reddy.K, Mohamed Boucadair, Philipp Tiesel, 2023-10-23, This document defines a secure transport for HTTP in which the client and server roles are reversed. This arrangement improves the origin server's protection from Layer 3 and Layer 4 denial-of-service attacks when an intermediary is in use. It allows origin server's to be hosted without being publicly (and directly) accessible but allows clients to access these servers via an intermediary. "Transmission of IPv6 Packets over Short-Range Optical Wireless Communications", Younghwan Choi, Cheol-min Kim, Carles Gomez, 2024-03-04, 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 how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. "Advertisement of Candidate Path Validity Control Parameters using BGP-LS", Ran Chen, Detao Zhao, Ketan Talaulikar, Yisong Liu, Changwang Lin, 2024-03-01, 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. "Generic Address Assignment Option for 6LowPAN Neighbor Discovery", Luigi Iannone, Zhe Lou, 2024-03-01, 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 recursively assign addresses and prefixes to nodes in a 6LowPAN deployment. "Traffic Engineering Extensions for Enhanced DetNet", Quan Xiong, Bin Tan, Zongpeng Du, Junfeng Zhao, Chang Liu, Dong Yang, 2023-10-23, As per [I-D.ietf-teas-rfc3272bis], DetNet can also be seen as a specialized branch of TE. As it is required to provide enhancements for data plane in scaling networks, this document proposes a set of extensions for traffic engineering to achieve the differentiated DetNet QoS in enhanced DetNet. "Some Refinements to Network Topologies (RFC8345)", Nigel Davis, Olga Havel, Benoit Claise, 2024-01-10, This draft provides a brief analysis of the current unidirectional point-to-point approach to modeling of the link in RFC8345, highlights why this is not sufficient and makes a proposal to enhance RFC8345 YANG to support multipoint uni/bi links. The two alternative enhancement approaches proposed are backward compatible. The enhancement is such that it provides a uniform solution to modeling all links that could, over time, replace the current unidirectional point-to-point approach. The rationale for the change is based on many years of practical experience, including challenges using RFC8345 in actual solution development, and insight gained through other standardisation efforts and deployments. "Computing resource notification domain in network", Yuexia Fu, 2023-10-23, This document introduces the definiation and the requirements of notification domain, and also introduces the process of service scheduling decision based on the notification domain in the network. "IPSec for BGP Enabled Services over SRv6", Haibo Wang, Linda Dunbar, Cheng Sheng, Hang Shi, 2024-01-26, This document describes an approach to encrypting selective user data flows using IPsec and then orchestrating the encrypted flows based on the SRv6 Policy path. The method is needed for some users or applications that demand an elevated level of security, necessitating the encryption of their data flows even within networks like SRv6, which are built and managed by Network Service Providers (NSP) and generally considered secure. Employing encryption for selective flows over NSP managed networks, including technologies like SRv6, adds an extra layer of protection, safeguarding valuable data from potential breaches and enhancing overall network security. "Usage of BGP-LS-SPF in Multi-segment SD-WAN", Cheng Sheng, Hang Shi, 2023-10-22, 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, 2024-03-03, 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. "VPN Inter-AS Option BC", Zhaohui Zhang, Kireeti Kompella, Bruno Decraene, Luay Jalil, 2024-02-06, RFC 4364 specifies protocol and procedures for BGP/MPLS IP Virtual Private Networks (VPNs), including different options (A/B/C) of Inter-AS support. This document specifies MPLS VPN Inter-AS Option BC that combines the advantages of Option B and Option C (and that removes the disadvantages of Option B and Option C). The same concept is applicable to Ethernet Virtual Private Network (EVPN) as well. "AI-Based Distributed Processing Automation in Digital Twin Network", Oh Seokbeom, Yong-Geun Hong, Joo-Sang Youn, Hyunjeong Lee, Hyun-Kook Kahng, 2023-10-23, This document discusses the use of AI technology and digital twin technology to automate the management of computer network resources distributed across different locations. Digital twin technology involves creating a virtual model of real-world physical objects or processes, which is utilized to analyze and optimize complex systems. In a digital twin network, AI-based network management by automating distributed processing involves utilizing deep learning algorithms to analyze network traffic, identify potential issues, and take proactive measures to prevent or mitigate those issues. Network administrators can efficiently manage and optimize their networks, thereby improving network performance and reliability. AI-based network management, utilizing digital twin network technology, also aids in optimizing network performance by identifying bottlenecks in the network and automatically adjusting network settings to enhance throughput and reduce latency. By implementing AI-based network management through automated distributed processing, organizations can improve network performance, and reduce the need for manual network management tasks. "BRSKI-CLE: A Certificateless Enrollment framework in BRSKI", Lei YAN, 2023-10-23, The Class 1 constrained IoT devices, defined in RFC7228, may be unable to use certificates within limited RAM. Exiting enrollment protocols of BRSKI are all using certificates. This document defines a certificateless enrollment framework in BRSKI (BRSKI-CLE) for constrained IoT devices. Considering the evolution towards quantum- safe algorithms, the framework is based on Key Encapsulation Mechanism (KEM). Cooperating with the authentication mechanism shown in I-D.selander-lake-authz, a constrained IoT device does not need to configure a public key to identify itself for the whole bootstrapping process. An authentication centre (AC) is used for issuing lightweight credentials, such as CBOR Web Tokens (CWTs), to constrained IoT devices. This document does not specify any lightweight credentials. "Advertise NRP Group extensions for IGP", Weiqiang Cheng, Changwang Lin, Liyan Gong, 2024-01-07, 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. "Additional MLS Credentials", Richard Barnes, Suhas Nandakumar, 2024-03-04, This specification defines two new kinds of credentials for use within the Message Layer Security (MLS) credential framework: UserInfo Verifiable Credentials and multi-credentials. UserInfo Verifiable Credentials allow clients to present credentials that associate OpenID Connect attributes to a signature key pair held by the client. Multi-credentials allow clients to present authenticated attributes from multiple sources, or to present credentials in different formats to support groups with heterogeneous credential support. "EVPN Anycast Aliasing For Multi-Homing", Jorge Rabadan, Kiran Nagaraj, Alex Nichol, Nick Morris, 2024-02-07, The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function addresses the load balancing of unicast packets from remote Network Virtualization Edge (NVE) devices to the NVEs that are multi-homed to the same CE, irrespective of the learning of the CE's MAC/IP information on the NVEs. This document describes an optional optimization of the EVPN multi-homing Aliasing function - EVPN Anycast Aliasing - that is specific to the use of EVPN with NVO3 tunnels (i.e., IP tunnels) and, in typical Data Center designs, may provide savings in terms of data plane and control plane resources in the routers. "A Transaction Ledger Verifiable Structure for COSE Merkle Tree Proofs", Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, 2024-01-12, This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced by Trusted Execution Environments (TEEs) to provide stronger tamper-evidence guarantees. "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, 2024-01-10, 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. "PCEP extension to support Candidate Paths validity", Ran Chen, Detao Zhao, Samuel Sidor, Mike Koldychev, Zafar Ali, 2024-03-01, 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, Mohamed Boucadair, Zongpeng Du, John Drake, 2024-01-11, 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. "Adaptive Stateless TE Multicast", Huaimo Chen, Mike McBride, Yanhe Fan, Zhenbin Li, Xuesong Geng, Mehmet Toy, Gyan Mishra, Yisong Liu, Aijun Wang, Lei Liu, Xufeng Liu, 2023-10-21, This document describes a multicast solution which provides adaptive stateless traffic engineering along an explicit P2MP path/tree. Each portion of the tree is encoded by a most efficient encoding method. A tree portion includes all or some of the links/branches/subtrees from any number of nodes on the tree. An IPv6 extension header is used to encapsulate a packet which is to be multicast at the ingress. The overhead of the encapsulated packet is minimal. The packet is delivered to the egresses along the tree. There is no state stored in the core of the network. "Merkle Tree Ladder Mode (MTL) Signatures", Joe Harvey, Burt Kaliski, Andrew Fregly, Swapneel Sheth, 2023-12-12, 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 SPHINCS+ (and the SLH-DSA subset specified in the draft FIPS 205), the stateless hash-based signature scheme selected by NIST for standardization. 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. "IGP for Temporal Links", Huaimo Chen, Aijun Wang, Gyan Mishra, Zhenqiang Li, Yanhe Fan, Xufeng Liu, Lei Liu, 2024-01-31, This document specifies extensions to OSPF and IS-IS for temporal links whose costs are functions of time. "Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP)", Michael Tuexen, Hannes Tschofenig, 2024-03-04, This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP). 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. "Control Architecture of Optical Pluggables in Packet Devices Under ACTN POI Framework", Nigel Davis, Reza Rokui, Praveen Maheshwari, Uday Joshi, Bhavit Vadhadiya, Xitiz Dave, Aihua Guo, 2023-09-29, This draft presents an additional architectural option for control of packet over optical networks by extending and complementing the IETF draft-poidt-ccamp-actn-poi-pluggable and by introducing an additional approach for control of optical plugs in packet devices. It provides the direct read/write access of coherent plugs to the optical controller, thereby allowing the end-to-end optical service management. The approach, introduced in this draft, can be further generalized to support other uses cases. The architectural option for control of packet over optical networks, introduced by this draft, also provides a clear separation between control of packet functions and control of optical functions. The packet and optical controls are partitioned so that the functions specializing in control of the optical capabilities can control corresponding functions in packet devices, optical devices or both without interfering with packet control functions. "Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks", Adrian Farrel, Daniel King, XingZhao, 2023-10-22, Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular, with many 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, ACTN 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. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful API capabilities. "The Use of Attestation in OAuth 2.0 Dynamic Client Registration", Hannes Tschofenig, Jan Herrmann, Ned Smith, Thomas Hardjono, 2023-10-23, The OAuth 2.0 Dynamic Client Registration specification described in RFC 7591 describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain information to interact with this authorization server, including an OAuth 2.0 client identifier. To offer proper security protection for this dynamic client registration some security credentials need to be available on the OAuth 2.0 client. For this purpose RFC 7591 relies on two mechanisms, a trust-on-first-use model and a model where the client is in possession of a software statement (a sort-of bearer token). This specification improves the security of the OAuth 2.0 Dynamic Client Registration specification by introducing the support of attestation. "Routing in Dragonfly+ Topologies", Dmitry Afanasiev, Roman, Jeff Tantsura, 2024-03-04, This document provides an overview of Dragonfly+ network topology and describes routing implementation for IP networks with Dragonfly+ topology with support for non-minimal routing.t "MIMI Portability", Konrad Kohbrok, Raphael Robert, 2024-01-04, This document describes MIMI Portability mechanisms. "MIMI Attachments", Raphael Robert, Konrad Kohbrok, 2024-01-04, This document describes MIMI Attachments. "Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies", Luis Contreras, Hitoshi Asaeda, 2023-10-23, The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. "Privacy Pass Token Expiration Extension", Scott Hendrickson, Christopher Wood, 2024-03-18, This document describes an extension for Privacy Pass that allows tokens to encode expiration information. "Using QUIC to traverse NATs", Marten Seemann, Eric Kinnear, 2024-03-03, QUIC is well-suited to various NAT traversal techniques. As it operates over UDP, and because the QUIC header was designed to be demultipexed from other protocols, STUN can be used on the same UDP socket, enabling ICE to be used with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test the viability of an address candidate pair while at the same time creating the NAT bindings required for a direction connection, after which QUIC connection migration can be used to migrate the connection to a direct path. "Packed CBOR: Table set up by reference", Christian Amsuess, 2024-03-04, Packed CBOR is a compression mechanism for Concise Binary Object Representation (CBOR) that can be used without a decompression step. This document introduces a means for setting up its tables by means of dereferencable identifiers, and introduces a pattern of using it without sending long identifiers. "Intent-Based Network Management in SRv6 network", J., PARK, Yunchul Choi, Jaehoon Jeong, 2023-11-10, This document describes secure network management in Segment Routing version six (SRv6) network. It proposes a framework empowered with Intent-Based Networking (IBN). The Intent-based Network Management (IBNM) in this document specifies an architectural framework with system components and interfaces. Also, this framework builds on Interface to Network Security Functions(I2NSF). "Tolerating Mailing-List Modifications", Wei Chuang, 2024-02-20, Mailing-lists distribute email to multiple recipients by forwarding and potentially modifying messages to document the distribution to the recipients. Unfortunately forwarding breaks SPF (RFC7208) authentication and message modification breaks DKIM (RFC6376) authentication. This document is based on ARC (RFC8617) to provide a framework to describe forwarding with extensions to tolerate common mailing-list message modifications. This specification characterizes the mailing-list transforms such that a receiver can reverse them to enable digital signatures verification and attribution of the message content. These message modifications are: 1) adding a description string to the Subject header, 2) rewriting the From header, 3) removing the original DKIM-Signature and 4) appending a footer to the message body. This also specifies those modifications for the purpose of making them reversible. "Encoding 3GPP Slices for Interactive Media Services", Tianji Jiang, Dan Wang, 2023-10-23, Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in the 3GPP SA2 working group. It targets at achieving high data rate, ultra-low latency, and high reliability. The streams of an XRM service might be comprised of data from multiple modalities, namely, video, audio, ambient-sensor and haptic detection, etc. XRM service faces challenges on various aspects, e.g. accurate multi-modality data synchronization, QoS differentiation, large volume of packets, and etc. While a new 3GPP network slice type, HDLLC, has been recently introduced to handle the QoS requirements of XRM streams, the ubiquitously-existential encryption of packet header and/or payload post additional challenges to the transport of encoded video packets via 5GS. We have then discussed two potential IETF schemes, e.g., IP-DSCP based or UDP-option extension, that could be applied to 'expose' XRM QoS 'metadata' to 5GS. "DNS IPv6 Transport Operational Guidelines", Tim Wicinski, 2023-10-23, This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. "Guide for building an EC PKI", Robert Moskowitz, Henk Birkholz, Michael Richardson, 2024-02-01, This memo provides a guide for building a PKI (Public Key Infrastructure) of EC certificates using openSSL. Certificates in this guide can use either ECDSA or EdDSA. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. "The Restatement Anti-Pattern", Carsten Bormann, 2024-03-02, 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. "secp256k1-based DHKEM for HPKE", Riad Wahby, 2023-10-15, This memo defines DHKEM-secp256k1, a variant of HPKE DHKEM (RFC9180) built on the secp256k1 elliptic curve. "CBOR: On Deterministic Encoding", Carsten Bormann, 2024-03-03, 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. "Associated Gateway Exchange in Multi-segment SD-WAN", Cheng Sheng, Hang Shi, Linda Dunbar, Gyan Mishra, 2024-02-29, 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. "Changing XML Syntax for RFCs", Martin Thomson, 2023-10-03, The authoritative version of RFCs are published in an XML format. This format is chosen for its ability to capture semantic details. A policy governing how the RFC XML format changes is described. "ESP Echo Protocol", Lorenzo Colitti, Jen Linkova, Michael Richardson, 2024-02-29, This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets. "Consideration for TVR (Time-Variant Routing) Requirements", Jing Wang, Peng Liu, 2023-09-26, This document makes some supplements to TVR's requirements, including advertisement, identification, classification of node attributes, and appropriate system settings. "End Marker in 5G Data Network", Zhaohui Zhang, Marco Liebsch, Tianji Jiang, 2024-02-06, In a mobile network, when a mobile device (referred to as User Equipment or UE) moves from one Access Node (source AN) to another (target AN), the anchoring node that connects the UE to the Data Network sends an End Marker to the source AN after it starts sending UE traffic towards the target AN. The target AN buffers the data until it receives the End Marker forwarded by the source AN. This is to preserve the order of packets during the handover between ANs. The anchoring node is referred to as User Plane Function (UPF) in 5G and it is a Network Function of the mobile network. The UPFs are traditionally centrally deployed but are more and more distributed closer to the edge. With distributed UPFs, handover becomes necessary among UPFs, and the End Marker mechanism may need to be extended to Data Network devices that are not mobile network functions. This document discusses the problem and proposes a solution based on ICMP messages if packet ordering needs to be preserved during handover between UPFs. "Computing-Aware Traffic Steering (CATS) Using LISP", Sun Kj, Tran Ngoc, Ha-Duong Phung, Younghan Kim, 2024-01-22, This document describes the usage of Locator/ID Separation Protocol (LISP) as a solution to implement Computing-Aware Traffic Steering (CATS). How LISP meets CATS requirements and how it fits to the control plane and data plane of CATS framework are presented. "ACME PQC Algorithm Negotiation", Alexandre Giron, 2024-02-16, ACME is a critical protocol for accelerating HTTPS adoption on the Internet, automating digital certificate issuing for web servers. Because RFC 8555 assumes that both sides (client and server) support the primary cryptographic algorithms necessary for the certificate, ACME does not include algorithm negotiation procedures. However, in light of Post-Quantum Cryptography (PQC), many signature algorithm alternatives can be used, allowing for different trade-offs (e.g., signature vs. public key size). In addition, alternative PQC migration strategies exist, such as KEMTLS, which employs KEM public keys for authentication. This document describes an algorithm negotiation mechanism for ACME. The negotiation allows different strategies and provides KEMTLS certificate issuing capabilities. "Metaverse and ICN: Challenges and Use Cases", Cedric Westphal, Hitoshi Asaeda, 2023-10-23, This document considers some challenges for ICN support of Metaverse- type applications from a networking perspective. Also, one use case is presented to promote one of our future visions. "The Requirements of a Unified Transport Protocol for In-Network Computing in Support of RPC-based Applications", Haoyu Song, Wenfei Wu, Dirk Kutscher, 2024-01-24, In-network computing breaks the end-to-end principle and introduces new challenges to the transport layer functionalities. This draft provides the background of a suite of RPC-based applications which can take advantage of INC support, surveys the existing transport protocols to show they are insufficient or improper to be used in this context, and lays out the requirements to develop a general transport protocol tailored for such applications. The purpose of this draft is to help understand the problem domain and inspire the design and development a unified INC transport protocol. "Signaling Additional SRTP Context information via SDP", Kyzer Davis, Esteban Valverde, Gonzalo Salgueiro, 2024-01-10, This document specifies additional cryptographic attributes for signaling additional Secure Real-time Transport Protocol (SRTP) cryptographic context information via the Session Description Protocol (SDP) in alongside those defined by RFC4568. The SDP extension defined in this document address situations where the receiver needs to quickly and robustly synchronize with a given sender. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. "Selective Disclosure CWTs (SD-CWT)", Michael Prorock, Orie Steele, 2024-03-03, This document describes how to perform selective disclosure of claims withing a CBOR Web Token (CWT) [RFC8392] as well as how to create and verify those tokens. This document does not define any new cryptography. "Hybrid IANA Registration Policy", John Klensin, 2024-02-09, 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. "MIMI Transport", Konrad Kohbrok, Raphael Robert, 2023-09-21, This document defines an HTTPS based transport layer for use with the MIMI Protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Source for this draft and an issue tracker can be found at https://github.com/kkohbrok/mimi-transport. "Interoperable Private Identity Discovery for E2EE Messaging", Giles Hogben, Femi Olumofin, 2023-11-05, This document specifies how users can privately discover each other's Service Specific Identifiers (SSIs) when using end-to-end encrypted messaging services across multiple providers. Users can retrieve SSIs without revealing their social graphs to service providers they are not delivering messages through, using their phone numbers, email, user IDs, or other Service Independent Identifiers (SIIs). Our specification can be based on private information retrieval or associative private sets membership schemes, both of which provide reasonable tradeoffs between privacy and cost. "Framework for CID Flow Indicator (CIDFI)", Dan Wing, Tirumaleswar Reddy.K, Mohamed Boucadair, 2023-12-14, Host-to-network signaling and network-to-host signaling can improve the user experience to adapt to network's constraints and share expected application needs, and thus to provide differentiated service to a flow and to packets within a flow. The differentiated service may be provided at the network (e.g., packet prioritization), the server (e.g., adaptive transmission), or both. This document describes how clients can communicate with their nearby network elements so they can learn network constraints. Optionally, with QUIC server support their incoming QUIC packets can be mapped to metadata about their contents so packet importance can influence both intentional and reactive management policies. The framework handles both directions of a flow. "MPLS Encapsulation for Deterministic Latency Network Action", Xueyan Song, Quan Xiong, Rakesh Gandhi, 2023-10-15, This document specifies formats and principles for the MPLS header which contains the Deterministic Latency Network Action (DLNA) option, designed for use over a DetNet network with MPLS data plane. It enables guaranteed latency support and makes scheduling decisions for time-sensitive service running on DetNet nodes that operate within a constrained network domain. "First-Party Approved Third-Party Certifications in OpenPGP", Daniel Gillmor, 2024-03-01, An OpenPGP certificate can grow in size without bound when third- party certifications are included. This document describes a way for the owner of the certificate to explicitly approve of specific third- party certifications, so that relying parties can safely prune the certificate of any unapproved certifications. "Unicode Character Repertoire Subsets", Tim Bray, Paul Hoffman, 2023-10-12, This document discusses specifying subsets of the Unicode character repertoire for use in protocols and data formats. "BBS for PrivacyPass", Watson Ladd, 2024-02-26, Existing token types in privacy pass conflate attribution with rate limiting. This document describes a token type where the issuer attests to a set of properties of the client, which the client can then selectively prove to the origin. Repeated showings of the same credential are unlinkable, unlike other token types in privacy pass. "JSON semantic format (JSON-NTV)", Philippe Thomy, 2023-12-19, This document describes a set of simple rules for unambiguously and concisely encoding semantic data into JSON Data Interchange Format. These rules are based on an NTV (Named and Typed Values) data structure applicable to any simple or complex data. The JSON-NTV format is its JSON translation. "Infight Removal of IPv6 Hop-by-Hop and Routing Headers", Tom Herbert, 2024-02-22, This document specifies an experimental method to allow routers to remove IPv6 Hop-by-Hop Options or Routing headers from packets in- flight. The goal is to reduce the probability of packets being dropped because they contain extension headers, without adversely impacting functionality. An additional goal is to limit visibility of information in extension headers to those nodes that need to process the headers. "Signaling MNA Capability Using IGP and BGP-LS", Ran Chen, Detao Zhao, 2024-03-01, This document defines a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS). "Mobile Subscription Info in DHCP and Router Advertisement", Saravanan Muthusamy, Yiu Lee, Ruchi Kothari, 2023-11-06, In some environments where a mobile client joins a network via simple DHCP process and/or IPv6 Router Advertisement, the serving network may want to know the mobile client's mobile subscription information. This is particularly useful when a mobile client switches to a private Wi-Fi network such as home network which uses simple SSID/ Pre-Shared-Key combination. The network can use the mobile subscription information to identify the client's serving mobile network and provide service continuity. "MIMI Discovery Requirements and Considerations", Jonathan Rosenberg, Jon Peterson, 2024-03-04, This document defines requirements and use cases for the discovery problem in the More Instant Messaging Interoperability (MIMI) working group. The discovery problem refers to the process by which a message sender can identify the provider(s) associated with a desired messaging recipient, who is normally identified by an email address or phone number. "An Architecture for More Instant Messaging Interoperability (MIMI)", Richard Barnes, 2024-03-04, The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. "The eap.arpa domain and EAP provisioning", Alan DeKok, 2024-02-25, This document defines the eap.arpa domain as a way for EAP peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers leverage user identifier portion of the Network Access Identifier (NAI) format of RFC7542 in order to describe what kind of provisioning they need. A table of identifiers and meanings is defined. "Use Cases for SPICE", Michael Prorock, Brent Zundel, 2024-03-03, 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. "Congestion Signaling (CSIG)", Abhiram Ravi, Nandita Dukkipati, Naoshad Mehta, Jai Kumar, 2024-02-02, This document presents Congestion Signaling (CSIG), an in-band network telemetry protocol that allows end-hosts to obtain visibility into fine-grained network signals for congestion control, traffic management, and network debuggability in the network. CSIG provides a simple, low-overhead, and extensible packet header mechanism to obtain fixed-length summaries from bottleneck devices along a packet path. This summarized information is collected over L2 CSIG-tags in a compare-and-replace manner across network devices along the path. Receivers can reflect this information back to senders via L4+ CSIG reflection headers. CSIG builds upon the successful aspects of prior work such as switch in-band network telemetry (INT) that incorporates multibit signals in live data packets. At the same time, CSIG's end-to-end mechanism for carrying the signals via fixed size header is simple, practical and deployable akin to Explicit Congestion Notification (ECN). In addition to a detailed description of the end-to-end protocol, this document also motivates the use cases for CSIG and the rationale for design choices made in CSIG. It describes a set of signals of interest to applications (minimum available bandwidth, maximum link utilization, and maximum hop delay), methods to compute these signals in network devices, and how these signals can be leveraged in applications. Additionally, it describes how attributes about the bottleneck's location can be carried and made useful to applications. It also provides the framework to incorporate future signals. Finally, this document addresses incremental deployment, backward compatibility and nuances of CSIG's applicability in a range of scenarios. "COSE Header Parameter for Carrying OpenID Federation 1.0 Trust Chains", Giuseppe De Marco, John Bradley, 2024-02-05, The CBOR Object Signing and Encryption (COSE) [RFC9053] message structure uses message headers to give references to elements that are needed for the security and verifiability of the message, such as algorithms and keys. OpenID Federation 1.0 [OIDC-FED] is a general purpose attestation mechanism to obtain verifiable metadata and cryptographic keys. This document defines a new COSE header parameter to identify and transport an OpenID Federation 1.0 Trust Chain. "Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions", Marc Blanchet, Christian Huitema, Dean Bogdanovic, 2024-03-04, Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. Up to now, communications have been done on a layer-2 point to point basis, with sometimes the use of relays, therefore no layer-3 networking was possible. RFC4838 reports an assessment done around 25 years ago concluding that the IP protocol stack was not suitable for deep space networking. This result lead to the definition of a new protocol stack based on a store-and-forward paradigm implemented in the Bundle Protocol(BP). More recently, space agencies are planning to deploy IP networks on celestial bodies, such as Moon or Mars, ground, and vicinity. This document revisits the initial assessment of not using IP and provides solution paths to use the IP protocol stack, from IP forwarding to transport to applications to network management, in deep space communications. "Path Energy Traffic Ratio API (PETRA)", Alberto Rodriguez-Natal, Luis Contreras, Alejandro Muniz, Marisol Palmero, Fernando Munoz, 2024-03-18, This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. "JMAP extension for S/MIME signing and encryption", Alexey Melnikov, 2024-03-04, This document specifies an extension to JMAP for sending S/MIME signed and/or S/MIME encrypted messages, as well as automatic decryption of received S/MIME messages. [[This version presents an alternative syntax to revision 04 of https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender- extensions/]] "UAS Serial Numbers in DNS", Adam Wiethuechter, 2023-12-04, This document describes a way Uncrewed Aerial System (UAS) Serial Numbers are placed into and retrieved from the Domain Name System (DNS). This is to directly support DRIP-based Serial Numbers. "Discovery for BRSKI variations", Toerless Eckert, David von Oheimb, Esko Dijk, 2023-10-23, This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators. "Key Update of Multiple Nodes in a Secure Network", Zongpeng Du, 2023-09-18, This document describes a key update mechanism for a secure network, in which each network node can maintain a temporary key to decrypt packet or make a signature for the packets. "Model and Test Methods for LTE-V2X Physical Layer Key Distribution System", Yanzhao Yang, Peng Guo, Jiabao Yu, Aiqun Hu, 2023-10-16, There are several key distribution systems based on the physical layer of the LTE Vehicle-to-Everything (V2X) communication system, utilizing the random and high-agreement secret key generation schemes from noisy wideband channels. These systems are used in conjunction with physical layer authentication systems that are also based on physical characteristics. To characterize these systems, this document proposes a reference model and several test methods of main technical parameters of such systems, including average key generation rate as well as the consistency and the randomness of generated key bits. "PREOF IOAM Method for Deterministic Network Service Sub-layer", Xiaocong Qian, Quan Xiong, Fenlin Zhou, 2023-09-22, This document proposes an active IOAM method to PREOF monitor and troubleshoot for Deterministic Networking (DetNet) in its service sub-layer. The method uses a special PREOF-TRACE message to collect multiple types of information from the target flow's PREOF entities and to record them in the packet, and uses a PREOF-RESPONCE message to feed them back to the head node. It assists the DetNet to monitor and maintain the PREOF for the traffic flow. "Transferring Digital Credentials with HTTP", Eric Rescorla, Bradford Lassey, 2023-09-22, There are many systems in which people use "digital credentials" to control real-world systems, such as digital car keys, digital hotel room keys, etc. In these settings, it is common for one person to want to transfer their credentials to another, e.g., to share your hotel key. It is desirable to be able to initiate this transfer with a single message (e.g., SMS) which kicks off the transfer on the receiver side. However, in many cases the credential transfer itself cannot be completed over these channels, e.g., because it is too large or because it requires multiple round trips. However, the endpoints cannot speak directly to each other and may not even be online at the same time. This draft defines a mechanism for providing an appropriate asynchronous channel using HTTP as a dropbox. "MIMI Signaling Protocol", Travis Ralston, Matthew Hodgson, 2023-09-22, The MIMI signaling protocol describes a framework for user-level interactions in the overall MIMI protocol stack. The event structure can be used by control protocols described by [I-D.barnes-mimi-arch]. "MIMI Policy Envelope", Travis Ralston, Matthew Hodgson, 2023-09-22, The MIMI Policy Envelope describes a _policy control protocol_ and _participation control protocol_ for use in a room, applied at the user participation level, as described by [I-D.barnes-mimi-arch]. "A method to declare domain names that are not a subdomain of the primary domain as trustworthy", Valentin Binotto, 2023-09-24, This document describes a method by which the owners/administrators of a specific domain name can declare other domain names, which are not subdomains of the primary domain but are used by the owners/ administrators of the primary domain, as trusted by using TXT records in the DNS zone of the primary domain. "QUIC in Space", Christian Huitema, Marc Blanchet, 2023-09-24, This document discusses the challenges of running the QUIC transport over deep space links, where delays are in order of minutes and communications are based on scheduled time windows. Using the experience of various testbeds, it provides guidance to implementations to support this use case. This document may apply to other use cases that have similar characteristics, such as IoT in disconnected and distant settings. "Email Feedback Reports for DKIM Signers", Alex Brotman, 2023-10-23, Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This should allow the reporting entity to deliver reports via email 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. "The qpack_static_table_version TLS extension", Rory Hewitt, 2023-11-09, This document specifies a new "qpack_static_table_version" TLS extension to enable clients and servers to agree upon the version of the HTTP/3 QPACK Static Table to use for communications between them. It also defines a new IANA registry to be used for documenting and publishing the entries in the QPACK static table. "TLS Key Share Prediction", David Benjamin, 2024-03-17, 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. "Common Catalog Format for moq-transport", Suhas Nandakumar, Will Law, Mo Zanaty, 2023-11-30, This specification defines a Common Catalog specification for streaming formats implementing the MOQ Transport Protocol [MoQTransport]. Media over QUIC Transport (MOQT) defines a publish/ subscribe based unified media delivery protocol for delivering media for streaming and interactive applications over QUIC. The catalog describes the content made available by a publisher, including information necessary for subscribers to select, subscribe and initialize tracks. "Two-year terms for NomCom volunteers", Geoff Huston, Rich Salz, 2023-09-26, Each year the NomCom process is actually two processes -- finding out anew how to be a NomCom and conduct its business, and then undertaking the work of the NomCom in selecting individuals to undertake the various roles for which the NomCom has responsibility. This applies to both the chair and to the voting volunteer members of the NomCom. The inclusion of the past chair into the NomCom as a non-voting member mitigates this to some extent, but the past chair is constrained as to the level of advice that can be offerred. This acts an impediment to making concrete changes for future incarnations of the Nomcom that would improve the overall Nomcom process. The NomCom process could benefit from greater levels of continuity from year-to-year to reduce the amount of time taken to by the new Nomcom to define its intended mode of operation and allow the operation each incarnation of the Nomcom with a greater level of consistency. This document changes the term of office for NomCom voting volunteers from one to two years. It also changes the term of office for the NomCom Chair from two to three. "Constraining RPKI Trust Anchors", Job Snijders, Theo Buehler, 2024-02-08, 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. "A YANG model for Power Management", Tony Li, Ron Bonica, 2023-10-17, Network sustainability is a key issue facing the industry. Networks consume significant amounts of power at a time when the cost of power is rising and sensitivity about sustainability is very high. As an industry, we need to find ways to optimize the power efficiency of our networks both at a micro and macro level. We have observed that traffic levels fluctuate and when traffic ebbs there is much more capacity than is needed. Powering off portions of network elements could save a significant amount of power, but to scale and be practical, this must be automated. The natural mechanism for enabling automation would be a Yet Another Next Generation (YANG) interface, so this document proposes a YANG model for power management. "Research Agenda for a Post-Quantum DNSSEC", Andrew Fregly, Roland van Rijswijk-Deij, Moritz Mueller, Peter Thomassen, Caspar Schutijser, Taejoong Chung, 2023-09-26, 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. "BGP Community-based Attacks and Community Origin Authentication", Yunhao Liu, Jessie Wang, Yangyang Wang, Mingwei Xu, 2023-09-27, BGP community usage has continued to increase during the past decade. Unfortunately, while BGP community is a seemingly innocuous feature, it can be used to influence routing in unintended ways. Existing defense mechanisms are insufficient to defend community-based attacks. This document describes some of the scenarios that may be used to launch these attacks and make recommendations on practices that may defend them. In particular, this document proposes SecCommunity, an extension to the Border Gateway Protocol (BGP) that can authenticate the ASes who added action community values on the announcements. "Resource Guarantee for SRv6 Policies", Weiqiang Cheng, Jiang Wenying, Ran Chen, Detao Zhao, Changwang Lin, 2023-10-21, 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. "Request to the Trustees of the IETF Trust to Permit the Creation of Derivative Works", Martin Thomson, Eric Rescorla, Timothy Terriberry, 2023-09-27, The IETF Trust holds rights to RFCs. This document updates RFC 5377 to request that the IETF Trust change its licensing for IETF documents to permit the creation of derivative works. "SCION Data Plane", Corine de Kater, Nicola Rustignoli, Samuel Hitz, 2024-03-04, 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 responsibility 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 first provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers - these are described, too. The document then shows the life cycle of a SCION packet while traversing the SCION Internet. This is followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. SCION also includes its own protocol to communicate failures to endpoints, the SCION Control Message Protocol (SCMP). This protocol will be described in a separate document, which will follow later. "Expect Signed Mail", Daniel Gillmor, Aron Wussler, 2023-10-01, This draft proposes a mechanism for e-mail users to indicate to their peers that the peer should expect all future e-mail from them to be cryptographically signed. "External Keys For Use In Internet X.509 Certificates", Mike Ounsworth, Markku-Juhani Saarinen, John Gray, D. Hook, 2023-10-03, Many of the post quantum cryptographic algorithms have large public keys. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and algorithms for referencing external public key data by hash, and location, for example URL. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. "CMAF Packaging for moq-transport", Will Law, Luke Curley, 2023-10-02, Packaging CMAF content for use with moq-transport. "Host to Network Signaling", Tom Herbert, 2023-10-04, This document discusses the motivations, use cases, and requirements for Host to Network Signaling. In Host to Network Signaling, hosts annotate packets with information that is intended for consumption by on-path elements. Signals may be used to request services on a per packet basis from on-path elements, to request admission into the network, or to provide diagnostics and tracing information. "New Protocols Must Require TLS 1.3", Rich Salz, Nimrod Aviram, 2023-10-05, TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Since TLS 1.3 use is widespread, new protocols must require and assume its existence. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. "Attracting people from emerging regions into the IETF", S Moonesamy, 2023-10-05, In 2013 the IETF Chair set up a Diversity Design Team to determine how to address issues such as geographic diversity. This document attempted to address the challenge of attracting people from emerging regions who can contribute to IETF work into the IETF. "Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification", Daniel Migault, Joel Halpern, U. Parkholm, Daiying Liu, 2023-10-06, IPsec supports "classifier" mechanism to send traffic with specific Differentiated Services Field Codepoints (DSCP) over different tunnels. However, such classification is not explicitly notified to the other peer. This document specifies the DSCP Notification Payload, which, in a CREATE_CHILD_SA Exchange, explicitly mentions which DSCP code points will be tunneled in the newly created tunnel. "Lightweight Bundle Protocol Edge Node with Zero-Configuration and Zero-State", Brian Sipos, 2023-10-23, This document explains how to use existing protocols, registries, code points, and algorithms to operate a Bundle Protocol (BP) edge node within a stable, non-challenged local underlayer IP network without the need for prior BP-layer configuration or long-term state. The purpose of this is to significantly lower the barrier to entry for lightweight BP edge nodes intended to act as endpoints for one (or only a few) BP applications. "Extending the Network - Host Requirements", Ole Troan, 2023-10-06, This memo describes the behaviour of a node that when connecting to a network, offers connectivity via itself to other nodes (or entities needing addresses) connected to it. The focus is on IPv6 connectivity, but the same principles could be applied to IPv4. "Mounting YANG-Defined Information from Remote Datastores", Alexander Clemm, Eric Voit, Aihua Guo, Ignacio Martinez-Casanueva, 2023-10-23, This document defines a mechanism, Peer-Mount, that allows YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that reference data nodes in other YANG subtrees and subsequently allowing those data nodes to be accessed by client applications as if they were part of the same local data hierarchy. In addition, means to manage and administer tho mount points are provided. This facilitates the development of applications that need to access network-wide data that treanscends individual network devices while ensuring network-wide data consistency. One example concerns example applications that require a network inventory and/or network topology with access to select management data within the nodes that comprise it. The concept of Peer-Mount was first introduced in an earlier Internet Draft that was no longer pursued due to lack of interest at the time. It is being revived now in light of renewed IETF interest in network inventory, network topology, and related use cases, for which Peer- Mount is of specific interest. Other concepts defined in the earlier draft, notably Alias-Mount, are not considered here since they provide other capabilities that are less applicable to those topics. "BGP Operations for Inter-domain SAV", Xueyan Song, Chunning Dai, 1211176911910469110103, Changwang Lin, 2024-01-26, This document attempts to present deployment considerations of source address validation using BGP protocol in inter-domain network. "Domain Name System in Mostly Isolated Networks", Marc Blanchet, 2023-11-05, This document lists operational methods to enable local DNS name resolving on an isolated network, where that target network may have intermittent reachability to Internet and/or have very long delays, disabling the real-time query and response flow to the authoritative name servers on Internet. "Carrying Traffic Shaping Mechanism in IPv6 Extension Header", haisheng yu, zkc, 2023-10-08, Starting from the traffic shaping mechanism, one of the core technologies of network deterministic assurance, we summarize the characteristics of different traffic scheduling and shaping methods and propose a solution design for IPv6 to carry these traffic scheduling and shaping methods, taking into account deterministic and security factors. At the same time, the network scope of practical applications is becoming larger and larger, and the demand for deterministic network services will no longer be restricted to LANs, but will require deterministic forwarding beyond LAN boundaries, extending the deterministic assurance capability previously provided in LANs to WANs through network layer technologies. "DTN IP Neighbor Discovery (IPND)", Daniel Ellard, Richard Altmann, Alex Gladd, Daniel Brown, Ronald in 't Velt, Scott Johnson, 2023-10-09, Delay and Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement “beacons.” Beacon messages are addressed to an IP unicast, multicast, or broadcast destination to discover specified or unspecified remote neighbors, or unspecified local neighbors in the topology, e.g. within wireless range. IPND beacons advertise neighbor availability by including the DTN node’s canonical endpoint identifier. IPND beacons optionally include service availability and parameters. In this way, neighbor discovery and service discovery may be coupled or decoupled as required. Once discovered, new neighbor pairs use advertised availabilities to connect, exchange routing information, etc. This document describes DTN IPND. "Information Awareness System for Computing-Aware Service Function Chain (IAS-CASFC): Security Service Aspect", Weilin Wang, Hua-chun Zhou, Jingfu Yan, 2023-10-10, This document describes the Information Awareness System of the Computing-Aware Service Function Chain (ISA-CASFC) from the security service aspect, including the system architecture, network, and computing information details. The SFC enables traffic to pass through the ordered Network Security Function (NSF) path, enabling end-to-end security services. Differences in the available network and computing resources cause performance differences between NSF instances deployed on different service sites. It can be seen that the routing decision on NSF instances will affect the quality of the security service. Therefore, it is necessary to implement the CA-SFC to ensure the quality of security service. This document extends the CATS framework and the CATS Computing and Network Information Awareness (CNIA) architecture for CA-SFC, and describes the network and computing information content for security service. "OpenPGP HTTP Keyserver Protocol", Daphne Shaw, Andrew Gallagher, 2024-03-04, 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. "BGP Extension for Distributing CP Threshold Constraints of SR Policy", Yisong Liu, Changwang Lin, Yuanxiang Qiu, 2023-10-10, This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. "PCEP Extension to Support Signaling Candidate Path Threshold Constraints of SR Policy", Yisong Liu, Changwang Lin, Yuanxiang Qiu, 2023-10-10, This document defines the extension of PCEP to signal the threshold and metric constraint parameters of candidate paths for SR Policy to support flexible path selection. "Best Current Practice for Workload Identity", Benedikt Hofmann, Hannes Tschofenig, 2023-10-10, The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and client_secret, can be complex and error-prone. "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads. This document specifies the use of JWTs for client credentials in container orchestration systems to improve interoperability in orchestration systems, to reduce complexity for developers, and motivates authorization server to support RFC 7523. "draft of dn protocol version 00", Mabingtao, 2023-10-10, TODO Abstract 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://devforma.github.io/internet-draft-template/draft-dn- protocol.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-devforma-dn-protocol/. Source for this draft and an issue tracker can be found at https://github.com/devforma/internet-draft-template. "EAP over IP", Hooman Bidgoli, Nick Morris, Nabeel Cocker, 2023-10-11, Extensible Authentication Protocol (EAP) is described in [RFC3748]. EAP typically runs directly over data link layers such as Point-to- Point Protocol (PPP) or IEEE 802, without requiring IP. IEEE802.1X-2004 clarifies some aspect of the EAP over Layer 2 PDUs. IEEE802.1X-2010 introduces MACsec Key Agreement Protocol (MKA) which uses EAPOL. In IEEE 802.1X-2010 the existing EAPOL (EAP over LANs) PDU formats have not been modified, but additional EAPOL PDUs have been added to support MKA. MKA is used for discovering peers and their mutual authentication, to agree the secrete keys (SAKs) used by MACsec for symmetric shared key cryptography. This document describes procedures to transport EAP and ultimately MKA PDUs over a IP network to distribute SAKs for symmetric key cryptography. "YANG Data Model for Scheduled Attributes", Yingzhen Qu, Acee Lindem, Eric Kinzie, Don Fedyk, Marc Blanchet, 2024-03-03, 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. "RFC 6296bis IPv6-to-IPv6 Network Prefix Translation", Margaret Cullen, Fred Baker, Ole Troan, Nick Buraglio, 2024-01-26, This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network 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/buraglio/rfc6296-bis. "Static Context Header Compression and Fragmentation for packets establishing a flow", Laurent Toutain, Ana Minaburo, 2023-10-12, This document describes how to compress the header of packets belonging to a flow using Static Context Header Compression and Fragmentation (SCHC) specifications. "Use of Hybrid Public-Key Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)", Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones, 2024-03-16, This specification defines Hybrid public-key encryption (HPKE) for use with Javascript 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. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with JOSE. "Computing-aware Traffic Steering for attack detection", Man Li, Hua-chun Zhou, Shuangxing Deng, Weilin Wang, 2023-10-13, This document describes the closed-loop framework for computing-aware traffic steering for attack detection (CATS-AD). The computing-aware traffic steering is determined by composing selected service instances and overlay links. The service instances are selected according to the computing power of service instances. This document describes the closed-loop framework for attacks detection and how to select and combine service instances to form a computing-aware service function chain (SFC). "Certificate Management over CMS (CMC)", Joe Mandel, Sean Turner, 2024-03-04, 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, 2024-03-04, 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 RFCs 5273 and 6402. "Certificate Management Messages over CMS (CMC): Compliance Requirements", Joseph Mandel, Sean Turner, 2024-03-04, 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 RFCs 5274 and 6402. "The Mastic VDAF", Hannah Davis, Dimitris Mouris, Christopher Patton, Pratik Sarkar, Nektarios Tsoutsos, 2024-03-04, This document describes Mastic, a two-party VDAF for the following aggregation task: each client holds a string, and the collector wishes to count how many of these strings begin with a given prefix. Such a VDAF can be used to solve the private heavy hitters problem, where the goal is to compute the subset of the strings that occur most frequently without learning which client holds which string. This document also describes different modes of operation for Mastic that support additional use cases and admit various performance and security trade-offs. "Classic McEliece", Simon Josefsson, 2023-10-13, This document specifies Classic McEliece, a particular family of encryption algorithms. 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. "Problem Statement:Collaborative Defense of DDoS Attacks", Yong Cui, Linzhe Li, Lei Zhang, 2023-10-23, This document presents a problem statement on collaborative mitigation of Distributed Denial-of-Service (DDoS) attacks. The evolving trends of DDoS attacks, including their types, intensities, and attack methods, pose formidable challenges to existing defense systems. This problem statement examines the current defense landscape, highlighting the distributed deployment of defense systems across various network positions and the imbalances in defense capabilities. Collaboration is crucial for effective DDoS attack mitigation, considering that a considerable number of attacks are spread across operators. The existing collaborative framework, DOTS, shows promise but requires addressing these challenges to enhance its efficacy. The existing collaborative framework DOTS demonstrates potential, but there are still numerous challenges in its practical application. This document aims to address these key issues that impact the implementation of collaborative technologies. "A Message Feedback Method for MPTCP", Baosen Zhao, Wanghong Yang, Wenji Du, Yongmao Ren, Xu Zhou, Gaogang Xie, 2023-10-16, Mobile phone devices are usually configured with multiple wireless access network cards, such as LTE/5G, Wi-Fi. And the wireless network is a network with highly time-varying bandwidth. For a single wireless device, the limited bandwidth cannot meet the peak rate requirements of low-latency applications. MPTCP supports the simultaneous use of multiple networks on mobile devices. Due to the time-varying nature of wireless networks, it is challenging for MPTCP to accurately schedule data blocks to different sub-streams to meet their low-latency requirements. This document proposes a new cross- layer feedback method for wireless networks to pass the scheduling information and status of the wireless network to the MPTCP Server. MPTCP Server can predict the transmission capacity of the wireless network based on this cross-layer information, thereby improving the efficiency of data block scheduling on multipaths. "IGP Flexible Algorithm with Link Loss", Wang Yifan, Guoqi Xu, Xuesong Geng, Jie Dong, 2024-02-20, IGP Flexible Algorithms allow IGPs to compute constraint-based paths. Since link packet loss rate plays an important role in network evaluation, links with high packet loss rate should be bypassed during forwarding. This draft proposes a path computation method based on a maximum link loss constraint to prune unsatisfied links in Flexible Algorithms. "RTP Payload for Haptics", Hyunsik Yang, Xavier de Foy, 2024-03-04, 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. "IS-IS and OSPF extensions for TVR (Time-Variant Routing)", Zheng Zhang, Haisheng Wu, Jing Wang, 2024-03-03, TVR needs IGP to calculate different results depending on the time, without convergence after the detection of link or nodes. IGP nodes need to learn the predictable and scheduled changes in advance. This document defines the IGP extensions for predictable and scheduled changes of TVR. "LTE-D Physical Layer Device Authentication Protocol", Yanzhao Yang, Peng Guo, Jiabao Yu, 2023-10-17, This document describes a physical layer device authentication protocol based on the physical layer unclonable fingerpint (PUF) technique for LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle- to-Everything), to help the LTE-D message receiver confirm the identity of the LTE-D message sender. PUF utilizes intrinsic nonlinear characters of the transmission signal to identificate the devices and coresponding wireless signal transmitters, and is suitable for critical vehicular communication scenarios by its immunity against traditional cryptographic attacks. The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism. "Implementation Guidelines for Authoritative DNS Proxies", Philip Homburg, 2023-10-17, In some situations it be can attractive to have an authoritative DNS server that does not have a local copy of the zone or zones that it serves. In particular in anycast operations, it is sensible to have a great geographical and topological diversity. However, sometimes the expected use of a particular site does not warrant the cost of keeping local copies of the zones. This can be the case if a zone is very large or if the anycast cluster serves many zones from which only a few are expected to receive significant traffic. In these cases it can be useful to have a proxy serve some or all of the zones. The proxy would not have a local copy of the zones it serves, instead it forwards request to another server that is authoritative for the zone. The proxy may have a cache. This document describes the details of such proxies. "A Common YANG Data Model for Scheduling", Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King, 2024-03-01, This document defines a common schedule YANG module which is designed to be applicable for scheduling information such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings. "A Framework of Data Express Service", Zongpeng Du, 2023-10-17, This document describes a potential framework for Data Express Service, and related technology requirements. "A Network Inventory Topology Model", Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair, 2023-10-18, This document defines a YANG model for network inventory topology to correlate the network inventory with the general topology to form a base underlay network, which can facilitate the mapping and correlation of the layer (e.g. Layer 2, Layer3) topology information above to the inventory resource of the underlay network for agile service provisioning and network maintenance analysis. "PFM-SD extension for EVPN multi-homing", Mankamana Mishra, IJsbrand Wijnands, Ryan Tucker, Hooman Bidgoli, Zhaohui Zhang, 2023-10-18, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services and in service provider (SP) applications for next-generation virtual private LAN services. EVPN defines sets of procedures to achieve multihoming between peers. When the multicast source is protected by EVPN multihoming for redundancy and multicast receivers are present behind PIM network, there are cases where traffic blackholes. PIM Flooding Mechanism (PFM) and Source Discovery (SD) define new flood mechanisms in PIM domain to carry information about source and group. This draft defines the necessary extension to PFM-SD procedures to have seamless integration with EVPN supported multihoming. "CDNI Metadata Expression Language", Will Power, Glenn Goldstein, Arnon Warshavsky, 2024-03-04, 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, 2024-03-04, 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. "Mapping YANG Data to Label-Set Time Series", Kristian Larsson, 2023-10-18, This document proposes a standardized approach for representing YANG- modeled configuration and state data, for storage in Time Series Databases (TSDBs) that identify time series using a label-set. It outlines procedures for translating YANG data representations to fit within the label-centric structures of TSDBs and vice versa. This mapping ensures clear and efficient storage and querying of YANG- modeled data in TSDBs. "BGP Flow Specification for Source Address Validation", Nan Geng, Dan Li, 2024-03-03, BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document specifies a new flow specification called Incoming- Interface-Set. Incoming-Interface-Set can be used together with the Source Prefix component to disseminate SAV rules. "A YANG Network Data Model of Network Inventory Software Extensions", Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair, 2023-10-18, This document defines the YANG model for network inventory software extensions to support more comprehensive software components and software-enabled network devices, e.g. virtual Provider Edge (PE), virtul Fire Wall (FW). This document augments the 'ietf-network-inventory' data model defined in xxx by adding the software components identification and new Network Element (NE) type. "A YANG Network Data Model of Network Inventory Entitlement/License", Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair, 2023-10-18, This document defines the YANG model for network inventory licenses/ entitlements. It provides licenses/entitlements information for network inventory management and facilitates fine-grained network inventory management. This document augments the 'ietf-network-inventory' data model defined in xxx by adding the licenses/entitlements attributes that are applicable to the Network Element (NE) and hareware and software components. "QUIC Address Discovery", Marten Seemann, 2024-02-28, 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. "IGP POI for Intra-domain SAV", Xueyan Song, Zenggui Kou, Yu Fu, Changwang Lin, 2024-01-23, This document describes an IGP Prefix Originated Indicator (POI) method for Source Address Validation (SAV) on routers to mitigate source address spoofing attack and improve the accuracy of source address validation in intra-domain networks. "SR based Loop-free implementation", Lijie Deng, Yongqing Zhu, Xuesong Geng, Zhibo Hu, 2023-11-22, 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. "IGP Extensions for Intra-Domain SAV", Huaimo Chen, Weiqiang Cheng, Aijun Wang, Gyan Mishra, Yanhe Fan, Xufeng Liu, 2024-02-01, This document specifies extensions to OSPF and IS-IS for Source Address Validation in Intra-domain. "TLS Trust Expressions", David Benjamin, Devon O'Brien, Bob Beck, 2024-03-04, This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. "A YANG Data Model for Microwave Radio Link", Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala, 2024-03-03, 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. "EAT profile for Intel® Trust Domain Extensions (TDX) attestation result", Greg Kostal, Sindhuri Dittakavi, Raghuram Yeluri, Haidong Xia, Jerry Yu, 2023-10-19, Intel® Trust Domain Extensions (TDX) introduces architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. "Recommendations for using Multiple IP Addresses in Benchmarking Tests", Gabor Lencse, Keiichi Shima, 2024-03-04, 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 it kept the usage of a single source and destination IP address pair when a single destination network is used. This limitation may cause an issue when the device under test uses Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two types of implementations: the first one only includes the IP addresses, whereas the second one also includes the port numbers into 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 in this case, the 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 it with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. "Coordinated Congestion Management", Lv Yunping, Yuhan Zhang, Mengzhu Liu, 2023-10-20, AI fabric is sensitive to bandwidth. Congestion management, including congestion control and load balancing, is a main method to fully utilize network resource. However, current congestion management mechanism are not coordinated, which leads to throughput decreasing. This document provides a scheme for coordinating different congestion management mechanisms. It describes the design principle, behaviors of network switches and hosts in the scheme, and gives an example to show end-to-end procedure. "Asset Lifecycle Management and Operations: A Problem Statement", Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez, 2023-10-20, This document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model is proposed whose primary objective is to measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. "Reliability in AI Networks Gap Analysis, Problem Statement, and Requirements", Weiqiang Cheng, Changwang Lin, wangwenxuan, 2023-10-20, This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. "Path Computation and Control Extention Requirements for Fine-Granularity Transport Network", Liuyan Han, Haomian Zheng, Minxue Wang, Yang Zhao, 2024-03-04, This document focuses on the requirements for path computation and control of the fine-granularity transport network. It provides the general context of the use cases of path computation and the considerations on the requirements of PCE extension in such fine- granularity transport network. "Power and Energy Efficiency", Jan Lindblad, Snezana Mitrovic, Marisol Palmero, Gonzalo Salgueiro, 2023-10-20, This document motivates and specifies a data model to report power and energy efficiency of an asset. As highlighted during the IAB workshop on environmental impacts (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental- impacts-report-00), visibility is a very important first step (paraphrasing Peter Drucker's mantra of "You cannot improve what you don't measure"). During the workshop the need for standardized metrics was established, to avoid proprietary, double counting and even contradictory metrics across vendors. This Power and Energy Efficiency Telemetry Specification (POWEFF) is required to promote consistency across vendors and consumers, based on: 1. The definition of datasets and attributes defining a common data model utilized by the standard calculation to yield power and energy efficiency value for any asset or network element. 2. The standard calculations utilizing the specified datasets and attributes which will yield energy consumption and energy efficiency value for any asset or network element. The model provides information and data requirements for calculating the Power and Energy Efficiency for specific assets. Assets can include hardware (physical or virtual), software, applications, or services. "An Application Layer Interface for Non-IP device control (NIPC)", Bart Brinckman, Rohit Mohan, Braeden Sanford, 2023-10-20, This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices. The described interface is extensible. This memo initially describes Bluetooth Low Energy and Zigbee as they are the most commonly deployed. "OAuth 2.0 for First-Party Applications", Aaron Parecki, George Fletcher, Pieter Kasselman, 2024-03-01, 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. "Reliability Framework for SRv6 Service Function Chaining", Feng Yang, Xiaoqiu Zhang, Changwang Lin, Yuanxiang Qiu, 2023-11-06, This document describes the framework for protection of service function chains in source routing networks. "IGP Color-Aware Routing", Changwang Lin, Mengxiao Chen, Liyan Gong, 2023-10-21, 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, 2023-10-21, 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. "Link failure detection by Ethernet data plane", Martin Hajduk, 2023-10-21, This document describes a method to detect link failures which relies solely on Ethernet data plane. An ordinary Ethernet frame can be modified and sent back to sender to signal a loss of connection. No control plane protocol is utilized in the process which makes the method very simple and fast to react. "Hybrid Computing and Network Awareness and Routing Solution for CATS", Xinxin Yi, Ran Pang, Hang Shi, 2023-10-22, Computing-Aware Traffic Steering (CATS) is a traffic engineering architecture that takes the dynamic changes of computing and network resources into account when forwarding traffic to appropriate service instances for processing. For the development of the current network, it is important to have a solution that meets different types of service requirements and can be deployed reasonably. Therefore, this document proposes a hybrid solution to provide differentiated and flexible traffic streering capabilities for different service while saving the cost of retrofitting existing network equipment. "Per Resource Events", Rahul Gupta, 2023-10-21, Per Resource Events is a minimal protocol built on top of HTTP that allows clients to receive notifications directly from any resource of interest. The Per Resource Events Protocol (PREP) is predicated on the idea that the most intuitive source for notifications about changes made to a resource is the resource itself. "Advertising Link and Node Security Properties in OSPF/IS-IS", Tony Przygienda, Acee Lindem, Vinayaka Guntanakkala, 2023-10-22, This document defines a way for an Open Shortest Path First (OSPF) or IS-IS router to advertise different security states at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular node/link or path meets security policies that have to be enforced. Here, the term "OSPF" means both OSPFv2 and OSPFv3. "Extension of Application-aware Networking (APN) Framework for Application Side", Zhenbin Li, Shuping Peng, 2023-10-22, The Application-aware Networking (APN) framework defines that application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. This document defines the extension of the APN framework for the application side. In this extension, the APN resources of an APN domain is allocated to applications which compose and encapsulate the APN attribute in packets. When the network devices in the APN domain receive the packets carrying APN attribute, they can directly provide fine-granular traffic operations according to these APN attributes in the packets. "DNS IPv6 Transport Operational Guidelines", Momoka Yamamoto, Tobias Fiebig, 2023-10-23, This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. It expands beyond [RFC3901] in so far that it now considers the reality of progressing IPv4 exhaustion, which will make IPv6-only resolvers necessary in the long-term. This document obsoletes RFC 3901. (if approved) "A Multiplane Architecture Proposal for the Quantum Internet", Diego Lopez, Vicente Martin, Blanca Lopez, Luis Contreras, 2024-03-04, 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. "RIFT in Dragonfly Topologies", Tony Przygienda, 2024-01-01, RIFT extensions for dragonfly topologies. "Philatelist, YANG-based collection and aggregation framework integrating Telemetry data and Time Series Databases", Jan Lindblad, 2023-10-22, 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 dependable and comparable results. "KeyPackage Context Extension for Message Layer Security (MLS)", Rohan Mahy, 2023-10-22, This document describes a Message Layer Security (MLS) KeyPackage extension to convey a specific context or anticipated use for the KeyPackage. It is useful when a client provides the KeyPackage out- of-band to another client, and wants the specific KeyPackage used only in the anticipated context, for example a specific MLS group. "An Alternative Path MTU Discovery for QUIC", Pyung Kim, 2023-10-22, This draft describes an alternative Path MTU Discovery (PMTUD) for QUIC. RFC 8899 searches for PMTU by sending a probe at the QUIC layer, which is an active probing approach. In this draft, a passive probing approach is adopted to discover the PMTU. The process of discovering the PMTU is not performed separately, but is performed simultaneously in the actual application data communication. That is, the actual application data is allowed to be carried in the process of discovering the PMTU. A probe packet is defined newly using 1-RTT packet which includes actual application data as well as a short packet header and a PING_EXT frame. The PING_EXT frame is also defined newly. Until the best PMTU is discovered, the size of the probe packet is changed according to the size of the PMTU candidate. A simple discovery algorithm using only the PMTU candidate sequence with linear upward is described in this draft. "Forward Erasure Correction for Short-Message Delay-Sensitive QUIC Connections", Dmitriy Moskvitin, Evgeny Onegin, Rachel Huang, Hanlin Luo, Qichang Chen, 2023-10-22, This document proposes a FEC scheme for single packet protection in accordance to the sender observed packet loss rate.. "Extended information of Semantic Definition Format (SDF) for Digital Twin", Hyunjeong Lee, Joo-Sang Youn, Yong-Geun Hong, 2024-03-04, An SDF specification can describe the definition of a Things, i.e., physical objects and their associated interactions and express the various information that be exchanged for the interactions. Therefore, the SDF format can be used to define the behaviour of an object and its associated data model and interaction model in a digital twin system that has an object as a component. In a digital twin system, interactions between physical and virtual objects, as well as interactions of objects existing in the different digital twin systems, are performed over a network, which is important to provide location information of objects during interactions. This document specifies the extension information of SDF to represent the location information of an objects. "Requirements from Control and Management Viewpoint for Collective Communication Optimization", Liu Chang, Xu Shiping, 2023-10-22, Collective communication optimization is a key means to improve the performance of distributed applications, due to that communication has become the bottleneck to degrade applications or business with the growth of the scale of distributed systems. The industry and academy has worked on proposing solutions to upgrade the collective communication operations. However, there has been the problem of lacking for unified guidelines. This draft provide requirements from the control and management viewpoint. "Advertising SaaS Path Performance Metrics using BGP", Cheng Sheng, Hang Shi, Linda Dunbar, 2023-10-22, 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. "BGP Flow Specification Extensions for Path Scheduling", Li Zhang, Tianran Zhou, Jie Dong, 2023-11-06, Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths. This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time. "SRH Reduction for SRv6 End.M.GTP6.E Behavior", Yuya Kawakami, Satoru Matsushima, Shay Zadok, Derek Yeung, Dan Voyer, 2024-03-01, 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. "ALTO Extension: Composition Mode of Cost Maps", Kai Gao, 2023-10-22, This document introduces an extension to the Application-Layer Traffic Optimization (ALTO) protocol, which enables announcements of the composition modes of multiple cost map services. Specifically, the composition mode defines how the results of multiple cost map services are combined to get the final prediction between two network endpoints. This extension allows ALTO servers to improve the accuracy of the prediction model at similar map sizes, and to efficiently enable differentiated services. "YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS)", Yingzhen Qu, Les Ginsberg, Tony Przygienda, 2024-03-03, The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). "Requirements from Control and Management Viewpoint for Collective Communication Optimization", Liu Chang, Xu Shiping, 2024-02-27, Collective communication optimization is crucial to improve the performance of distributed applications, due to that communication has become bottleneck to degrade applications with the growth of scale of distributed systems. The industry and academy has worked on proposing solutions to upgrade collective communication operations. However, there has been a problem of lacking for unified guidelines. This draft provide requirements on collective communication optimization from the control and management viewpoint. "Guidance for COSE and JOSE Protocol Designers and Implementers", Hannes Tschofenig, Les Hazlewood, 2023-10-22, JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) are two widely used security wrappers, which have been developed in the IETF and have intentionally been kept in sync. This document provides guidance for protocol designers developing extensions for JOSE/COSE and for implementers of JOSE/COSE libraries. Developers of application using JSON and/or JOSE should also read this document but are realistically more focused on the documentation offered by the library they are using. "A Usable Formal Methods Sample Problem from TEEP", Cory Myers, Hannes Tschofenig, 2023-11-05, This draft follows the invitation of [I-D.farrell-ufmrg-sample] to propose another sample problem for demonstration, training, and evaluation of formal methods in IETF work. It draws on recent work from the Software Updates for the Internet of Things [suit] and Trusted Execution Environment Provisioning [teep] working groups to define a sample modeling problem for a novel rather than a familiar IETF protocol. "Ethernet VPN Signalling Extensions for Bit-stream VPWS", Steven Gringeri, Jeremy Whittaker, Christian Schmutzer, Bharath Vasudevan, Patrice Brissette, 2023-10-23, This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). "CATS based on Real Locator", Hang Shi, Xia Chen, Zhenbin Li, Xinxin Yi, Kehan Yao, 2024-02-28, This document describes a solution framework that adheres to the CATS framework. The solution uses anycast IP addresses as the CATS service identifier and real locator of the service contact instance as the CATS Instance Selection ID. "Collective Communication Optimization: Problem Statement and Use cases", Kehan Yao, Xu Shiping, Yizhou Li, Hongyi Huang, Dirk KUTSCHER, 2023-10-23, Collective communication is the basic logical communication model for distributed applications. When distributed systems scales, the communication overhead becomes the bottleneck of the entire system, impeding system performance to increase. This draft describes the performance challenges when the collective communication is employed in a network with more nodes or processes participating in or a larger number of such communication rounds required to complete a single job. And the document presents several use cases where different aspects of collective communication optimization are needed. "SRv6 Migration Scenarios", Shraddha Hegde, Rajesh Shetty, Bharath Bhat, Dan Voyer, 2023-10-23, SRv6 forwarding plane requires devices to support processing newly defined Segment Routing extension header. All devices in the network may not be capable of processing this new header and may require gradual upgrade. This document specifies mechanisms that to deploy features such as TI-LFA, in the presence of SRH incapable devices in the network. "Data Model for Asset Lifecycle Management and Operations", Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez, 2023-10-23, This document includes a data model for assets lifecycle management and operations. The primary objective of the data model is to measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. This model is based on the information model introduced in "Asset Lifecycle Management and Operations: A Problem Statement" (ALMO) [I-D.draft-palmero-opsawg-ps-almo-00] IETF draft. "Enhanced Use cases for Scaling Deterministic Networks", Junfeng Zhao, Quan Xiong, Zongpeng Du, 2023-10-23, 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 and computing-aware applications, and analyzes the classification for the three typical use cases and applications. "Application Aware Computing Network", Zhenbin Li, Hang Shi, Xia Chen, Zongpeng Du, Shuai Zhang, 2024-02-28, This document describes a solution framework that adheres to the CATS framework. The solution uses APN as part of the CATS service identifier and flow identifier. "Differentiated DetNet QoS for Deterministic Services", Quan Xiong, Junfeng Zhao, Zongpeng Du, Qimiao Zeng, Chang Liu, 2023-10-23, This document describes the service requirements of scaling deterministic networks and proposes Differentiated DetNet QoS (DD- QoS) for deterministic services in enhanced DetNet. "Collective Communication Optimizations: Requirement and Analysis", Kehan Yao, Xu Shiping, Yizhou Li, Hongyi Huang, Weifeng Wang, Dirk KUTSCHER, 2024-02-04, Gernerative AI applications depend on large scale parallel computing clusters for model training and inference. Existing implementations of collective communication in parallel computing is built on top of RDMA, the most adoptable AI transport protocol. However, One-to- Many, Many-to-One, and Many-to-Many collective operations all depend on point-to-point transport semantics of RDMA, which inevitably introduces more bandwidth occupancy and transmission overhead. Emerging approaches for collective communication optimization focus on network-assisted collective acceleration and can work compatibly with RDMA. This document analyzes different technical schemes for network-assisted collective acceleration based on RDMA, and presents the gap between these work and current IETF standards, notably iWARP. Requirements for designing new standards are proposed accordingly. "the architecture for secure routing", Meiling Chen, Li Su, 2024-03-04, Some users need to choose nodes that meet security requirements to form secure routing and ensure that traffic can defend against dynamic attacks during path forwarding. In this architecture, there are four roles defined: attester, authorizer, controller and secfunction, the interaction of these four roles can achieve the selection of secure routing and security services. The purpose of this architecture is to secure the routing, including node static security assessment, dynamic security defense, and routing path and security service consistency validation. "IGP Extensions for DetNet Deterministic Links", Quan Xiong, Xiaocong Qian, 2023-10-23, This document proposes the deterministic links to provide a one- dimensional deterministic metric to guarantee the deterministic forwarding capabilities at different levels and proposes the deterministic links distribution by IGP extensions. "Necessity of Application-Network Collaboration in Wireless Access Scenarios", Tong Meng, Hang Shi, 2023-10-23, Emerging applications (e.g., extended reality, cloud gaming, and teleoperation) impose stringent bandwidth, latency, reliability requirements on network transport, so as to deliver immersive and interactive user experience. That drives recent discussion on application-network collaboration, especially in wireless access networks. To motivate participation from content and network providers, this memo elaborates the necessity of such collaboration while focusing on wireless access scenarios. "Application-aware Networking (APN) for Performance Enhancement of Media Service", Shuping Peng, Xuesong Geng, 2023-10-23, This draft explores the requirements and benefits of carrying media metadata in the network layer (i.e. IP packets) by following the Application-aware Networking (APN) framework with extension for the application side, and defines the specific carrying information and format. "Proposed Update to BGP Link-State SPF NLRI Selection Rules", Jie Dong, chenjinqiang, Sheng Fang, 2023-10-23, 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 update to the BGP-LS-SPF NLRI selection rules, so as to ensure a deterministic selection result. The proposed update can also help to mitigate some issues in BGP-LS-SPF route convergence. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp- spf. "Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)", Hannes Tschofenig, Hendrik Brockhaus, 2024-03-03, Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) define protocol messages for X.509v3 certificate creation and management. Both protocol provide interactions between client systems and PKI management entities, such as a Registration Authority (RA) and a Certification Authority (CA). CMP and EST allow an RA/CA to request additional information it has to provide in a certification request. When an end entity places attestation Evidence in a Certificate Signing Request (CSR) it may need to demonstrate freshness of the provided Evidence. Attestation technology today often accomplishes this task via the help of nonces. This document specifies how nonces are provided by an RA/CA to the end entity for inclusion in Evidence. "Automating DNS Delegation Management via DDNS", Johan Stenstam, 2024-03-04, 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 author (gratefully) accept pull requests. "Framework of Forwarding Commitment BGP", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, 2023-10-23, This document defines a standard profile for the framework of Forwarding Commitment BGP (FC-BGP). Forwarding Commitment(FC)is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, the goal of FC-BGP is to build a secure inter-domain system that can simultaneously authenticate AS_PATH attribute in BGP-UPDATE and validate network forwarding on the dataplane. "Framework of Forwarding Commitment BGP", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, 2023-10-23, This document defines a standard profile for the framework of Forwarding Commitment BGP (FC-BGP). Forwarding Commitment(FC)is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, the goal of FC-BGP is to build a secure inter-domain system that can simultaneously authenticate AS_PATH attribute in BGP-UPDATE and validate network forwarding on the dataplane. "Opportunistic TCP-AO with TLS", Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen, 2024-03-04, This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. "BMP Local Path-ID", Maxence Younsi, Pierre Francois, Paolo Lucente, 2024-03-18, Intelligence is required to track BGP paths throughout the various RIBs and VRFs of a routing platform, due to potential attribute modifications and the use of BGP multipath. This document introduces the option to identify a path within a router in order to ease correlation in monitoring. A BMPv4 TLV is defined in order to communicate this locally significant identifier in monitoring messages. "Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)", Marco Tiloca, 2024-02-12, This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). "IPFIX Alternate-Marking Information", Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Fabrizio Milan, Massimo Nilo, 2023-10-23, This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. "Considerations for Adjustments of Encapsulating Security Payload (ESP) Trailer", Wei Pan, Chenyuan Fang, 2023-10-23, Implementing IPsec in hardware is a way to improve the forwarding performance of IPsec. However, the current IPsec ESP packet design, i.e., the position of ESP trailer, imposes a new overhead challenge for implementing IPsec in hardware. This document explains how this overhead challenge occurs and proposes the possible solutions. "Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)", Marco Tiloca, Rikard Hoeglund, 2024-03-04, 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. This document defines a number of means to coordinate the use and discovery 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, it defines a well-known EDHOC application profile. "BGP over TLS/TCP", Thomas Wirtgen, Olivier Bonaventure, 2023-10-23, This document specifies the utilization of TCP/TLS to support BGP. "TLS Flag - Request mTLS", Jonathan Hoyland, 2024-02-18, 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. "Application-aware Networking (APN6) Header Authentication", liuy619@chinaunicom.cn, Shuai Zhang, Changwang Lin, Mengxiao Chen, 2023-10-23, This document proposes an authentication method to verify the application-aware networking (APN) header. "BIER Loop Avoidance using Segment Routing", Yisong Liu, Changwang Lin, Zheng Zhang, Yuanxiang Qiu, 2023-11-08, This document provides a mechanism leveraging SR-MPLS and/or 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, 2023-10-23, 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). "On the Operational Granularity of RPKI ROA Management: Problem Statement and Requirements", Yanbiao Li, Jiankang Yao, Di Ma, 2023-10-23, When using the Resource Public Key Infrastructure (RPKI) to perform route origin validation (ROV) with route origin authorizations (ROAs), there have been security and usability issues identified and reported. This memo revisits these issues from the perspective of the operational granularity of ROA management, demonstrates problems and their root cause with the existing ROA encoding scheme, summarizes design requirements to address them, and evaluates three potential solutions. Though neither of existing solutions satisfies all requirements, a hybrid solution composed of two existing schemes is recommended to use in ROA management. "Application-aware Data Center Network (APDN) Use Cases and Requirements", Haibo Wang, Kehan Yao, Wei Pan, Hongyi Huang, 2024-03-01, The deployment of large-scale AI services within data centers introduces significant challenges to established technologies, including load balancing and congestion control. Additionally, the adoption of cutting-edge network technologies, such as in-network computing, is on the rise within AI-centric data centers. These advanced network-assisted application acceleration technologies necessitate the flexible exchange of cross-layer interaction information between end-hosts and network nodes. The Application-aware Data Center Network (APDN) leverages the Application-aware Networking (APN) framework for application side to furnish the data center network with detailed application-aware information. This approach facilitates the rapid advancement of network-application co-design technologies. This document delves into the use cases of APDNs and outlines the associated requirements, setting the stage for enhanced performance and efficiency in data center operations tailored to the demands of AI services. "Notification for Adaptive Routing", Haibo Wang, Hongyi Huang, 2023-10-23, Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and improve link reliability. Adaptive routing (AR), which is widely used in direct topology such as dragonfly, can dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, in addition for the local node to apply AR, the congestion/failure information also needs to be sent to other nodes in a timely and accurate manner, so as to enforce AR in other nodes to avoid exacerbating congestion on the path. This document specifies Adaptive Routing Notification (ARN) for disseminating congestion detection and congestion elimination proactively. "EAP-FIDO", Jan-Frederik Rieckers, Stefan Winter, 2024-03-01, 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-janfred-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/. "Problem Statement, Use Cases, and Requirements of Hierarchical SFC with Segment Routing", nikangkang, Hongyi Huang, Yige Zhang, Jiaming Ye, 2024-03-02, Hierarchical Service Function Chaining (hSFC) is a network service chaining method that utilizes a hierarchical structure to efficiently organize and manage service function chains, enhancing network performance and scalability. This document primarily describes the use case of hSFC, which is the security resource pool. It outlines the associated problem statement and requirements for the security resource pool. The document aims to assist in identifying candidate solution architectures and solutions. "Post-Quantum Cryptography Recommendations for Internet Applications", Tirumaleswar Reddy.K, 2024-03-01, Post-quantum cryptography brings some new challenges to applications, end users, and system administrators. This document describes characteristics unique to application protocols and best practices for deploying Quantum-Ready usage profiles for applications using TLS. "A YANG Data Model for WDM Tunnels", Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero, 2023-10-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). "IRTF Code of Conduct", Colin Perkins, 2024-03-04, This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and diversity of participation. Through this code of conduct, the IRTF will continue to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect "A Bound End-to-End Tunnel (BEET) mode for ESP", Antony Antony, Steffen Klassert, 2023-10-23, This document specifies a new mode for IPsec ESP, known as Bound End- to-End Tunnel (BEET) mode. This mode complements the existing ESP tunnel and transport modes, while enhancing end-to-end IPsec usage. It offers the characteristics of the tunnel mode but without its usual overhead. The BEET mode is designed to accommodate evolving applications of ESP, such as minimalist end-to-end tunnel, mobility and multi-address multi-homing. Additionally, this document proposes a new Notify Message, USE_BEET_MODE, for the Internet Key Exchange Protocol Version 2 (IKEv2) specified in [RFC7296], to facilitate BEET mode Security Association negotiation. "Static Context Header Compression and Fragmentation for Zero Energy Devices", Edgar Ramos, Lorenzo Corneo, Ana Minaburo, 2023-10-23, This document describes the use of SCHC for very constraint devices. The use of SCHC will bring connectivity to devices with restrained use of battery and long delays. "Application of Explicit Measurement Techniques for QUIC Troubleshooting", Alexandre Ferrieux, Igor Lubashev, Giuseppe Fioccola, Isabelle Hamchaoui, Massimo Nilo, Fabio Bulgarella, Mauro Cociglio, 2024-03-04, This document defines an extension to the QUIC transport protocol to allow 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). "Ultra-Low Latency Cryptography Areion", Yumi Sakemi, Satoru Kanno, 2023-10-23, This document specifies a series of cryptographic wide-block permutations named "Areion"[Areion] for efficient encryption and hashing of relatively short input data. Additionally, it describes AEAD scheme constructed from Areion. "An Approach to Expose 'Device Models'-as-'Network Models'", Oscar de Dios, Victor Lopez, Mohamed Boucadair, 2023-10-23, This document describes an approach for exposing Device Models as Network Models (DMaNM). In particular, this document provides guidance for structuring a data model to facilitate the reuse of device models within the customer-facing interface of Software- Defined Networking (SDN) controllers. The objective of this approach is to enhance the reusability of device models in various network scenarios and ease the mapping between network/service models with device models. "Happy Eyeballs Version 3: Better Connectivity Using Concurrency", Tommy Pauly, David Schinazi, Nidhi Jaju, Kenichi Ishibashi, 2024-03-04, 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. "Benchmarking Methodology for Reliable Transport Protocols in Integrated Space and Terrestrial Networks", Zeqi Lai, Qi Zhang, Hewu Li, Qian Wu, Jihao Li, 2023-10-23, This document defines the terminology and methodology for conducting performance benchmarking of the transport protocols for low-earth orbit satellite user terminals within emerging integrated space and terrestrial networks (ISTN). It encompasses the test environment setup and benchmarking tests. The objective of this document is to enhance the applicability, repeatability, and transparency of performance benchmarking for transport protocols in ISTN. "Post-quantum cryptography migration use cases", Antonio Vaira, Hendrik Brockhaus, Alexander Railean, John Gray, Mike Ounsworth, 2024-03-04, This document is meant to be continuously updated, to incorporate emerging Post-Quantum Cryptography (PQC) migration use cases, with a focus on the migration from traditional signature algorithms (e.g., RSA, DSA, ECDSA) to PQC signature algorithms (e.g., LMS, XMSS, ML- DSA, SLH-DSA). This document aims at categorizing real-world scenarios based on a set of distinctive features. The primary goal is to facilitate discussions on migration strategies by offering a systematic taxonomy and a shared understanding among stakeholders. "On the difficulty of Quantum Cryptography in presence of packet losses", Davide Calsi, Paul Kohl, JinHyeock Choi, Janis Notzel, 2023-11-14, From the communication viewpoint, qubits are different from classical bits. A qubit may be transmitted directly but it can’t be cloned or measured without altering its state, so existing copy-and-resend schemes can’t be used to handle a transmission failure. Moreover, in some cases, the sender does not know the state of the transmitted qubit, so a qubit loss may cause irrevocable damage. This draft presents the causes of transmission failures, and analyses the vulnerabilities of several crypto protocols that such defects may bring forth. Thus, quantum teleportation is highly recommended for certain applications. "RTP Payload Format for Geometry-based Point Cloud Compression", Mathis Engelbart, Joerg Ott, Lukasz Kondrad, 2023-10-23, 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 signall properties of the RTP stream. The parameters can be used with Session Description Protocol (SDP). "System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements", Paulo Correia, Pamela Dingle, 2023-10-23, 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. "X.509-based Attestation Evidence", Mike Ounsworth, Hannes Tschofenig, 2023-10-23, This document specifies Claims for use within X.509 certificates. These X.509 certificates are produced by an Attester as part of the remote attestation procedures and consitute Evidence. This document follows the Remote ATtestation procedureS (RATS) architecture where Evidence is sent by an Attester and processed by a Verifier. "Path Computation Based on Precision Availability Metrics", Luis Contreras, Fernando Agraz, Salvatore Spadaro, 2024-02-13, 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. "Requirements for Securing SCTP Traffic using DTLS", Michael Tuexen, 2023-10-23, The current specification of DTLS over SCTP is outdated and does not fulfill the requirements of 3GPP. This Internet Draft documents the requirements of 3GPP for securing SCTP based communications using DTLS. It is a result of a design team in TSVWG and reflects the current of its work. Therefore, this document is expected to change over time. "Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS)", Toerless Eckert, Michael Menth, Steffen Lindner, 2024-03-04, BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. "EVPN L3-Optimized IRB", Ali Sajassi, Chuanfa Wang, Krishnaswamy Ananthamurthy, Jorge Rabadan, 2024-03-04, Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) provides dynamic and efficient intra and inter-subnet connectivity among Tenant Systems and end devices while maintaining very flexible multihoming capabilities. This document describes how EVPN-IRB can be optimized for IP hosts and devices such that PE devices only maintain MAC addresses for locally-connected IP hosts,thus improving MAC scalability of customer bridges and PE devices significantly. This document describes how such optimization is acheived while still supporting host moblity which is one of the fundamental features in EVPN and EVPN-IRB. With such optimization PE devices perform routing for both intra and inter-subnet traffic which results in some some caveats that operators and service providers need to be fully aware of. "A Mechanism for X.509 Certificate Discovery", Tomofumi Okubo, Corey Bonnell, John Gray, 2023-10-23, 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. "QUIC Data Channels", Mathis Engelbart, Joerg Ott, 2023-10-23, WebRTC data channels provide data communication between peers with varying reliability and ordering properties. WebRTC data channels traditionally use SCTP layered on top of DTLS over UDP. This document describes how WebRTC data channels can be layered over QUIC. "Multiplexing RTP and Data Channels over QUIC", Mathis Engelbart, Joerg Ott, 2023-10-23, This document defines a multiplexing scheme for using RTP over QUIC and QUIC Data Channels in a single QUIC connection. 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/mengelbart/draft-engelbart-multiplex-roq-qdc. "Path Validation Problem Statement, History, Gap Analysis and Use Cases", Peter Liu, Qin WU, Liang Xia, 2023-10-23, This document provides a problem statement, history revisiting, gap analysis and use cases for path validation techniques. "Layer 2 Relay Agents in Cellular Fronthaul Networks", Claudio Porfiri, Jari Arkko, 2023-10-23, The fronthaul portion of a cellular network is the part of the network that connects centralized radio controllers and the distributed radio units at the edge of the cellular network. A switched fronthaul network is one where the connectivity is provided through one or more stages of switches. When performing address assignment and configuration tasks in such networks, knowledge of how the different devices are connected is beneficial. Networks that employ IPv6 can use DHCPv6 to support Relay Agents. However, those networks that continue to be based on IPv4 have no easy way to support this, as the DHCPv4 support for relays is limited. This document explores how to provide Relay Agent functionality in IPv4-based switched fronthaul networks. "Aggregation Trace Option for In-situ Operations, Administration, and Maintenance (IOAM)", Alexander Clemm, Metzger, 2023-10-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. "SR Path Binding Protection Architecture", Huaimo Chen, Zhibo Hu, Weiqiang Cheng, Aijun Wang, Gyan Mishra, 2024-02-01, This document describes a architecture of fast re-route protection for binding SIDs on SR paths including SRv6 paths and SR-MPLS paths. The SR paths are in a single domain or cross two domains. The two domains are administrated by one provider or two different providers. "CDNI Logging Extensions", Ben Rosenblum, Omar Ramadan, Kenton Seward, 2024-03-04, 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. "Secure Telephone Identity for Message Layer Security", Jon Peterson, Richard Barnes, 2024-03-04, This document specifies Message Layer Security (MLS) Credential Types for use with Secure Telephone Identity Revisited (STIR), one for STIR certificates and another for the Personal Assertion Token (PASSporT). "Safe Congestion Control", Matt Mathis, 2023-10-23, We present criteria for evaluating Congestion Control Algorithms (CCAs) for behaviors that have the potential to cause harm to Internet applications or users. Although our primary focus is the safety of transport layer congestion control, many of these criteria should be applied to all protocol layers: entire stacks, libraries and applications themselves. "Security and Operational concerns in ACTN POI work", P. Doolan, H. Bock, 2023-10-23, Work in CCAMP on POI in ACTN is at an early stage and does not yet seem to have adequately described some of the operational or security concerns which may impact the real world applicability of any resulting work product "Large Record Sizes for TLS and DTLS", John Mattsson, Hannes Tschofenig, Michael Tuexen, 2024-03-04, RFC 8449 defines a record size limit extension for TLS and DTLS allowing endpoints to negotiate a record size limit smaller than the protocol-defined maximum record size, which is around 2^14 bytes. This document specifies a TLS flag extension to be used in combination with the record size limit extension allowing endpoints to use a record size limit larger than the protocol-defined maximum record size, but not more than about 2^16 bytes. "X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs", Rohan Mahy, 2024-03-16, RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates "Structured Email: Trust and security considerations", Hans-Joerg Happel, 2023-10-23, This document discusses trust and security considerations for "structured email" ([I-D.happel-structured-email-00]) and provides recommendations for message user agents on how to deal with structured data in email messages. "LDP Extensions to Support Private Line Emulation (PLE)", Christian Schmutzer, 2023-10-23, This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks. "Kademlia-directed ID-based Routing Architecture (KIRA)", Roland Bless, 2023-10-23, This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA offers highly scalable zero-touch IPv6 connectivity, i.e., it can connect hundred thousands of routers and devices in a single network (without requiring any form of hierarchy like areas). It is self-organizing to achieve a zero-touch solution that provides resilient (control plane) IPv6 connectivity without requiring any manual configuration by operators. It works well in various topologies and is loop-free even during convergence. The architecture consists of the ID-based network layer routing protocol R²/Kad in its routing tier and a Path-ID-based forwarding tier. The topological independent IDs can be embedded into IPv6 addresses, so that KIRA provides zero-touch IPv6 connectivity between KIRA nodes. "Centralized Anycast Gateway in Ethernet VPN(EVPN)", Neeraj Malhotra, Krishnaswamy Ananthamurthy, Ali Sajassi, Lukas Krattiger, Jorge Rabadan, 2024-03-04, 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. "More Instant Messaging Interoperability (MIMI) using HTTPS and MLS", Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert, 2024-03-04, 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. "Joint Exposure of Network and Compute Information for Infrastructure-Aware Service Deployment", Sabine Randriamasy, Luis Contreras, Jordi Ros-Giralt, Roland Schott, 2024-03-04, Service providers are starting to deploy computing capabilities across the network for hosting applications such as distributed AI workloads, AR/VR, vehicle networks, and IoT, among others. In this network-compute environment, knowing information about the availability and state of the underlying communication and compute resources is necessary to determine both the proper deployment location of the applications and the most suitable servers on which to run them. Further, this information is used by numerous use cases with different interpretations. This document proposes an initial approach towards a common understanding and exposure scheme for metrics reflecting compute and communication capabilities. "Current Process for Handling RFC Errata Reports", Alice Russo, Jean Mahoney, 2024-02-27, 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. "Differential Privacy Mechanisms for DAP", Junye Chen, Audra McMillan, Christopher Patton, Kunal Talwar, Shan Wang, 2023-10-23, Differential Privacy (DP) is a property of a secure aggregation mechanism that ensures that no single input measurement significantly impacts the distribution of the aggregate result. This is a stronger property than what systems like the Distributed Aggregation Protocol (DAP) are designed to achieve. This document describes a variety of DP mechansisms applicable to DAP, and, for a variety of common use cases, lifts DAP to a protocol that also achieves DP. "BGP Flow Specification Version 2", Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke, 2023-10-23, 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. IDR requires two implementations prior to standardization. Implementers feedback on FSv2 was that the complete FSv2 has the contains the correct information, but that breaking FSv2 into a progression of documents would be helpful. The first priority in this progression is expanded IP DDOS capabilities. This document contains original FSv2 IP DDOS capabilities in FlowSpec v2 using just the extended communities to define actions. "OAuth Client and Device Metadata for Nested Flows", Aaron Parecki, 2023-10-23, This specification defines a vocabulary and method of transmitting information about an OAuth client when a user is redirected through one or more authorization servers during an OAuth flow. This provides the deeper nested authorization servers with additional context that they can use for informational or revocation purposes. "Next Header Option in UDP Options", Daiya Yuyama, Hirochika Asai, 2023-10-23, This document defines the next header option in UDP options. The next header option specifies the protocol immediately following the UDP header. "Hybrid signature spectrums", Nina Bindel, Britta Hale, Deirdre Connolly, Florence D, 2024-02-22, 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 compatiblity, 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-hale-pquip-hybrid- signature-spectrums "Batched Signatures", David Joseph, Deirdre Connolly, Carlos Aguilar-Melchor, 2023-11-04, This document proposes a construction for batch signatures where a single, potentially expensive, "base" digital signature authenticates a Merkle tree constructed from many messages. Discussion of this work is encouraged to happen on the IETF TLSWG mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/PhDJsandboxaq/draft-joseph-batch- signatures "TurboTLS for faster connection establishment", Douglas Stebila, David Joseph, Carlos Aguilar-Melchor, Jason Goertzen, 2023-11-04, This document provides a high level protocol description for handshaking over UDP in the Transport Layer Security (TLS) protocol (version independent). In parallel, a TCP session is established, and once this is done, the TLS session reverts to TCP. In the event that the UDP handshaking portion fails, TurboTLS falls back to TLS- over-TCP as is usually done, resulting in negligible latency cost in the case of failure. 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/PhDJsandboxaq/draft-ietf-turbotls- design/. "BIER Anycast MPLS Label", Siyu Chen, Fanghong Duan, 2024-03-17, This document provides a method to reduce packet loss when failures occur at BIER transit or egress nodes or link. "Online Certificate Status Protocol (OCSP) Nonce Extension", himanshu sharma, 2023-11-08, This document updates the Nonce extension section of RFC-8954. Nonce extension is a optional extension for Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 8954. "Mail Autoconfig", Ben Bucksch, 2024-01-31, Set up a mail account with only email address and password. 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://benbucksch.github.io/autoconfig-spec/draft-autoconfig-1.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-autoconfig-1/. Source for this draft and an issue tracker can be found at https://github.com/benbucksch/autoconfig-spec. "Referencing big external files in email messages", Bron Gondwana, Alexey Melnikov, 2023-11-06, This document specifies a way to reference big attachments in email messages without including them inline. "YANG Full Embed", Jean Quilbeuf, Benoit Claise, Thomas Joubert, 2024-03-04, YANG lacks re-usability of models defined outside of the grouping and augmentation mechanisms. For instance, it is almost impossible to reuse a model defined for a device in the context of the network, i.e by encapsulating it in a list indexed by device IDs. [RFC8528] defines the YANG mount mechanism, partially solving the problem by allowing to mount an arbitrary set of schemas at an arbitrary point. However, YANG mount is only focusing on deploy or runtime. This document aims to provide the same mechanism at design time. "Augmented-by Addition into the IETF-YANG-Library", Zhuoyao Lin, Benoit Claise, Ignacio Martinez-Casanueva, 2024-03-04, This document augments the ietf-yang-library in [RFC8525] to provide the augmented-by list. It facilitates the process of obtaining the entire dependencies of YANG model, by directly querying the server's YANG module. 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. "SRv6 Security Considerations", Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, 2024-03-03, 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. "Basic Requirements for IPv6 Customer Edge Routers", Gabor Lencse, Jordi Martinez, Patton, Timothy Winters, 2024-03-04, 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. "Using HTTP/3 Stream Limits in HTTP/2", Martin Thomson, Lucas Pardue, 2023-11-06, A variant mechanism for managing stream limits is described for HTTP/2. This scheme is based on that used in QUIC and is more robust against certain patterns of abuse. "464 Customer-side Translator (CLAT): Node Recommendations", Jen Linkova, Tommy Jensen, 2024-02-28, 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 provides recommendations on when a node shall enable or disable CLAT. "Using Subnet-Specific Link-Local Addresses to Improve SLAAC Robustness", Jen Linkova, 2024-02-25, This document suggests that a link-local address used by a router as a source address for Router Advertisement packets is calculated as a function of prefixes listed in the Prefix Information Option of the Router Advertisement. The proposed approach, combined with the Rule 5.5 of the Default Source Address Selection algorithm (RFC6724) and first-hop selection requirements for hosts (RFC 8028) improves the robustness of the SLAAC by allowing the hosts to detect the IPv6 subnet changes much faster and select the correct source address. "Sustainability Considerations for Internetworking", Carlos Pignataro, Ali Rezaki, Suresh Krishnan, Hesham ElBakoury, Alexander Clemm, 2024-01-24, This document defines a set of sustainability-related terms to be used while describing and evaluating environmental impacts of Internet technologies. It also describes several of the design tradeoffs for trying to optimize for sustainability along with the other common networking metrics such as performance and availability. 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 implementors sustainability- related advice and guideance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. "Security Considerations for SRv6 Networks based on Deployment Experience", Yisong Liu, Dan Voyer, Akash Agarwal, 2023-11-10, This document discusses the security considerations for SRv6 networks based on the deployment experience. "EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay", Chongfeng Xie, Xing Li, Congxiao Bao, Mark Smith, 2023-11-08, 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. "Global Token Revocation", Aaron Parecki, 2024-03-01, Global Token Revocation enables parties such as a security incident management tool or an external Identity Provider to send a request to an Authorization Server to indicate that it should revoke all of the user's existing tokens and require that the user re-authenticates before issuing new tokens. "Usage specification of the otpauth URI format for TOTP and HOTP token generators", Ilteris Eroglu, 2023-11-09, This document describes a foundational schema for the otpauth URI, utilized by TOTP (and/or HOTP) based authenticators. "Explicit QUIC Path-ID extension", Christian Huitema, 2023-11-09, The work on QUIC multipath has almost converged, but we are still debating how to identify paths. The draft multipath version 06 identifies paths explicitly using the sequence number of the Connection Identifier used for sending packets on the path. The WG is considering an alternate proposal in which the path ID is explicit. In order to compare the two solutions, we propose here an extension to the multipath draft allowing endpoints to negotiate the use of explicit sequence numbers. When the extension is negotiated, endpoints announce new connection identifiers using a new MP_CONNECTION_ID frame, which carries the parameters of the NEW_CONNECTION_ID plus a path ID. This path ID is used instead of the CID sequence number to identify packet number spaces, to create encryption nonces, to identify paths in MP_ACK, MP_ABANDON, MP_AVAILABLE and MP_STANBY frames, and to perform the logic associated with path creation, path CID rotation, and NAT rebinding. The draft analyzes the pros and cons of using this extension. After experimentation and analysis, we expect that this extension will be either absorbed into a new version of the QUIc multipath draft, or abandoned. "Scalable Streaming Raster Graphics v1.0", Isabelle Santin, 2023-11-10, This document describes the Scalable Streaming Raster Graphics (SSRG) specification for the modern Web. An unfortunate truth of the modern internet is that digital equity has been secondary to the expansion of broadband in the most developed areas of the world. This in turn makes it much harder for developing nations to gain a competitive foothold in the digital market due to lackluster download speeds limiting access to content-rich applications and educational resources. The SSRG specification, dubbed "Surge" by its creator, intends to bridge "The Digital Divide" using techniques of classical quadtree image compression and Laplacian image pyramids to create a more scalable and equitable browsing experience for low-bandwidth users while still providing standard features such as perceptually lossless image quality at competitive compression rates. The format efficiently encodes a multi-resolution version of the stored image that can be streamed sequentially in order of increasing pixel resolution using conventional mechanisms of the HTTP protocol. The specification comes in three main parts: "An Alternate Path Model for Multipath QUIC", Bill Gage, 2023-11-11, The path model used in the current MPQUIC draft binds a connection identifier to a path. In fact, the sequence number of a connection identifier is used as an implicit path identifier. This has a number of consequences that may cause MPQUIC to diverge from the principles of RFC9000. One of these consequences, for example, is to associate each connection with a different application data packet number space rather than maintaining a single application data packet number space across all connections as defined in RFC9000. This document proposes a different path model for Multipath QUIC using explicit path identifiers, enabling a multipath management framework that retains the principles and operations of RFC9000. "Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)", Panos Kampanakis, Gerardo Ravago, 2024-02-19, [EDNOTE: The intention of this draft is to get IANA KE codepoints for ML-KEM. It could be a standards track draft given that ML-KEM will see a lot of adoption, an AD sponsored draft, or even an individual stable draft which gets codepoints from Expert Review. The approach is to be decided by the IPSECME WG. ] 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. "Mitigating QNAME minimization performance problems", John Levine, 2023-11-13, QNAME minimization improves DNS privacy by truncating query names sent to authoritative name servers. While it works well when there is a zone cut between each label in a name, when a zone includes more than one level of labels, it can cause multiple redundant queries to the same server, significantly increasing the load on that server without additional privacy benefits. This document describes some situations where minimization causes load problems and potential ways to fix the problem. "SCIM Delta Query", Anjali Sehgal, Danny Zollner, 2023-11-14, This document defines extensions to the System for Cross-domain Identity Management (SCIM) standard RFC7643 [RFC7644] to enable incremental retrieval of resources that have been updated or deleted in a SCIM service provider. This allows for more efficient interactions between SCIM clients and service providers and addresses problems that have inhibited large-scale implementation of use cases such as synchronization, entropy detection, and identity reconciliation. "The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR", Jilong Wang, Changqing An, Chengyuan Zhang, 2023-11-22, This memo presents the definition of a new DNS resouce record type named TLSR, and then discusses a new framework for certificate revocation and certificate status verification. This document can solve the existing problems in the current certificate revocation schemes. This requires matching improvements in TLS client software, but no change in TLS server software. "EPP Pre-Registration Verification", Jacques Latour, Don Slaunwhite, Tim Johnson, 2023-11-15, This Internet Draft introduces an extension to the Extensible Provisioning Protocol (EPP) for top-level domain (TLD) registries, enabling registrars to submit pre-registration information for domain names. The extension facilitates quality verification by the registry, employing advanced Artificial Intelligence and Machine Learning (AI/ML) techniques. Pre-registrations are assigned a quality score based on the analysis of the submitted data, ranging from 0 for non-abusive registrations to 100 for potentially abusive ones. This extension addresses the critical need to proactively identify and mitigate abusive domain registrations within TLDs, contributing to a safer and more reliable internet environment. The document outlines the EPP command definitions, XML schemas, data flow, and security considerations necessary to implement this innovative quality assurance mechanism, thereby enhancing the integrity and trustworthiness of TLD registrations. "QUIC Bandwidth Delay Product Tokens", Q Misell, 2024-01-22, This document describes a method to store previously calculated Congestion Control parameters on a QUIC client to allow additional capacity on high Bandwidth Delay Product paths to be used with Careful Resume. 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/theenbyperor/quic-bdp-token. "Identity Trust System", Luigi Sbriz, 2023-11-17, This document describes the identity trust system, which is an open identity authentication system that does not require federation of authentication domains. It is based on a symmetric authentication protocol and a specific infrastructure to ensure trust in the identity providers (IdPs). Regarding the main components: 1. Symmetric authentication protocol - Both entities MUST recognize each other and are authenticated by their identity provider according to a symmetric scheme. This protocol builds on and extends the OAuth Authorization Framework RFC6749. 2. Trustees' network - A special network, dedicated to creating a protected environment for exchanging authentication messages between IdPs, constitutes the infrastructure to avoid domain federation. 3. Custodian concept - IdPs are divided into two typologies to better protect personal data. A generic IdP (called trustee) for pure digital authentication and a specific IdP (called custodian) under the control of the country's authority with legal right to the individual's real data to ensure physical identity. "Update to Message Submission for Mail", John Levine, 2023-11-19, This memo adds updated advice for e-mail message submission. This memo also offers guidance to software that constructs a message envelope from a message's headers prior to submission. "QUIC Accurate ECN Acknowledgements", Marten Seemann, 2023-11-17, QUIC defines a variant of the ACK frame that carries cumulative count for each of the three ECN codepoints (ECT(1), ECT(0) and CE). From this information, the recipient of the ACK frame cannot deduce which ECN marking the individual packets were received with. This document defines an alternative ACK frame that encodes enough information to indicate which ECN mark each individual packet was received with. "Gender Representation in the IETF Nominating Committees", Mallory Knodel, 2024-01-17, This document extends the existing limit on nomcom representation by company in order to improve gender diversity by ensuring that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. "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, 2024-02-27, The IAB has 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. "Flooding Reduction in CLOS Networks", Xiaohu Xu, 2023-11-21, In a CLOS topology, an OSPF (or ISIS) router may receive identical copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors. Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or LSP) simultaneously. This results in unnecessary flooding of link- state information, which wastes the precious resources of OSPF (or ISIS) routers. Therefore, this document proposes extensions to OSPF (or ISIS) to reduce this flooding within CLOS networks. The reduction of OSPF (or ISIS) flooding is highly beneficial for improving the scalability of CLOS networks. "Deterministic Networks - Navigating Precision in Communication", Guangshuo Chen, Yuyin Ma, Liang Wang, Ying Zhou, 2023-11-22, This document offers a comprehensive overview of deterministic networks, elucidating their significance, key characteristics, and the challenges they address in comparison to non-deterministic counterparts. With a focus on Time-Sensitive Networking (TSN) and Precision Time Protocol (PTP), the technological aspects are explored, encompassing synchronization mechanisms, traffic shaping, and security considerations. Real-world applications in industrial automation, control systems, and multimedia streaming underscore the practical relevance of deterministic networks. The document emphasizes the importance of precise time synchronization, security measures, and collaboration within the networking community. Through acknowledgments, the collaborative efforts of the Deterministic Networking (DetNet) Working Group, authors of relevant standards, and the broader community are recognized, highlighting the collective dedication to advancing deterministic networking technologies. "OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows", Karsten zu Selhausen, Louis Jannett, Christian Mainka, 2023-11-23, This specification defines the web message response mode that authorization servers use for transmitting authorization response parameters via the user-agent's postMessage API to the client. This mode is intended for authorization flows that use secondary windows, which are well-suited for browser-based applications. "Fully Adaptive Routing Ethernet", Xiaohu Xu, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Shraddha Hegde, 2024-02-25, 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, 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 load balance traffic to the same destination over multiple ECMP 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, 2024-01-12, 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, 2024-01-12, 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. "Guidance for HTTP Capsule Protocol Extensibility", Lucas Pardue, 2023-11-23, This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. "Towards a CAP Theorem for Censorship Circumvention", Cory Myers, 2023-11-25, This Internet-Draft is a submission to the IAB Workshop on Barriers to Internet Access of Services [biasws]. 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-cfm-circumvention-cap- theorem/. Source for this draft and an issue tracker can be found at https://github.com/cfm/draft-cfm-circumvention-cap-theorem. "LibrePGP Message Format", Werner Koch, Ronald Tse, 2023-11-29, 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). "Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3", David Benjamin, Andrei Popov, 2023-11-29, 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. "RADIUS accounting via IPFIX", Alan DeKok, Stefan Winter, 2023-11-29, The Remote Authentication Dial In User Server (RADIUS) Protocol provides for a number of simple session-based metrics. There is a need to increase the number of metrics, and to add metrics for individual flows within a session. This document leverages IP Flow Information Export (IPFIX) to address both needs. "Path Tracing in SRv6 networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija, 2023-12-01, 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. "Export of Flow Precision Availability Metrics Using IPFIX", Alexander Clemm, Mohamed Boucadair, Greg Mirsky, 2023-12-04, This document defines a set of IP Flow Information Export (IPFIX) Information Elements to export precision availability data associated with Flows, specifically Flows that are associated with stringent Service Level Objectives (SLOs) such as latency or packet delay variation. "An HTTP Status Code to Report Requester Impairment", Richard Roda, 2023-12-12, This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when an operation or resource is denied due to requester impairment. "A Routing Architecture for Satellite Networks", Tony Li, 2024-02-21, Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links that are far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital mechanics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms, enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. "PKCS #15 Updates", Peter Gutmann, 2023-12-06, This document describes updates to the PKCS #15 standard made since the original publication of the standard. "Update to the use of Internet-Drafts in the Internet Standards Process", John Levine, 2024-01-31, This memo updates the way that Internet-Drafts are used in the Internet Standards Process. Rather than expiring, Internet-Drafts are marked Active or Inactive. Also, the rules for referencing Internet-Drafts in other documents are clarified. "AEGIS-based Cipher Suites for TLS 1.3, DTLS 1.3 and QUIC", Frank Denis, Samuel Lucas, 2023-12-07, This documents 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, 2023-12-07, 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. "Internet Control Message Protocol (ICMPv6) Loopback", Tal Mizrahi, Tianran Zhou, Shahar Belkar, Reuven Cohen, Justin Iurman, 2023-12-07, This document defines ICMPv6 Loopback, which enables a two-way packet exchange that can be used for probing and for diagnostic purposes. ICMPv6 Loopback is similar to ICMPv6 Echo, except that after a Loopback Request is sent, its corresponding Reply includes as much of the IPv6 Loopback Request packet as possible, including the IPv6 header and IPv6 extension headers and options if they are present. "Origin-Bound One-Time Codes", Eryn Wells, Theresa O'Connor, 2023-12-07, This specification defines a mechanism for associating one-time codes with domains that can be included in the body of an SMS message or the headers of an email. "BGP Flow Specification Extensions for Traffic Statistics", baolei, 2023-12-07, RFC8955 defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document extends RFC 8955 with New traffic Filtering Actions. statistic for bytes rate per second and statistic for packets rate per second are useful in specified Flow processing scenario. "Compensation Reference for Jitter Reduction Mechanism", Daorong Guo, YOU Xuejun, Rubing Liu, zhushiyin, 2023-12-10, This document describes several methods for obtaining reference delay applicable to different scenarios. These methods are in conjunction with mechanisms aimed at reducing end-to-end delay jitter in a scalable deterministic network. The goal is to meet specific business requirements and provide greater flexibility in the multipath planning for service protection. "Retiring the Tao of the IETF", Niels ten Oever, Greg Wood, 2024-02-26, This document retires and obsoletes the Tao of the IETF as an IETF- maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included as an annex. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way. "Paired MLS - PCS in Limited Modes", Elsie Fondevik, Britta Hale, Xisen Tian, 2023-12-13, 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, 2023-12-14, 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. "BGP Next-next Hop Nodes", Kevin Wang, Jeffrey Haas, 2023-12-14, BGP speakers learn their next hop addresse for NLRI in [RFC4271] in the NEXT_HOP field and in [RFC4760] in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. [I-D.ietf-idr-entropy-label] defines the "Next Hop Dependent Capabilities Attribute" (NHC) which allows a BGP speaker to signal the forwarding capabilities associated with a given next hop. This document defines a new NHC capability, the Next-next Hop Nodes (NNHN) capability, which can be used to advertise the next-next hop nodes associated with a given next hop. "Use cases with Requirements for Packet Optical Integration (POI) Under ACTN Framework", Oscar de Dios, Edward Echeverry, Reza Rokui, Nigel Davis, Bhavit Vadhadiya, Praveen Maheshwari, Italo Busi, Aihua Guo, 2023-12-18, This document provides general overarching guidelines for control and management of packet over optical converged networks and focuses on operators' use cases with requirements and network topologies. It provides a set of use cases and requirements which are needed to achieve full automation for 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 coherent pluggables. It is intended that other IETF drafts in this area reference this draft and abide by the use cases and requirements in this draft. The realization of these use cases is out of scope of this draft and shall be covered in other IETF drafts. "NTV tabular format (NTV-TAB)", Philippe Thomy, 2023-12-19, This document describes a set of simple rules for unambiguously and concisely encoding semantic tabular and multidimensional data (NTV- TAB format). These rules are based on the NTV structure and its JSON representation (JSON-NTV format). "Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC", Andrew Fregly, Joe Harvey, Burt Kaliski, Duane Wessels, 2023-12-19, 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. "URN Namespace for Metaverse Standards Forum Resources", Thomas Stockhammer, 2023-12-19, This document describes the Namespace IDentifier (NID) 'metaverse- standards-org' for Uniform Resource Names (URNs) used to identify resources published by Metaverse Standards Forum. The forum specifies and manages resources that utilize this URN identification model. Example resources include ressources, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, and other types of resources produced or managed by the Metaverse Standards Forum. "CoAP in Space", Carles Gomez, Sergio Aguilar, 2023-12-19, This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the scenario where an IP protocol stack is used for deep space communication. "Internet Wall", pradeep xplorer, 2023-12-21, To be able to say the owner of two emails are same like pradeep@4a2e.online = pradeepan88@hotmail.com "vCard Credentials", Orie Steele, 2023-12-26, vCard is a file format for digital business cards. This document enables vCards to be used as a transport for digital credentials. "Outer Header Translator", Naoki Matsuhira, 2024-02-25, 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. "NTS extensions for enabling pools", David Venhoek, Folkert de Vries, Marc Schoolderman, 2023-12-22, The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple downstream servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. "Digital Credential Profiles Best Current Practices", Orie Steele, Michael Prorock, Mahmoud Alkhraishi, 2023-12-22, Digital Credentials are frequently modeled on documents, forms, and messages that enable a holder to prove they have attributes that are acceptable to a verifier. This document provides guidance to verifiers enabling them to describe their requirements such that they can be translated into digital credential profiles. "Secure Shell Key Exchange Method Using Hybrid Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512", Simon Josefsson, 2023-12-26, This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on Classic McEliece (mceliece6688128) and X25519 with SHA-512. 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. "Ethernet over HTTPS Protocol", ARAM Salim-amine, 2023-12-28, This document defines a protocol for encapsulating Ethernet frames over HTTPS, allowing secure communication between a client and internal web servers. The protocol includes authentication using strong API keys encrypted with the server's public key. The communication is secured using TLS for privacy and integrity. "Recursively Setting Directories and Subitems", Zhang Mingqian, Rijesh Parambattu, Jing, Dongyu Geng, Zhongbing Jiang, Yunfei Du, 2023-12-27, In recent years, the concept of near-data computing has been widely recognized in storage architectures. The core idea is to process data nearby, reduce the overhead of network transmission, and utilize the computing capability of smart devices (such as intelligent NICs, smart SSDs, and DPUs). This reduces CPU and memory usage of clients (computing nodes) and improves data processing efficiency. This design idea is applied in NFSv4.2 or future NFS verions, such as Server-Side Copy, in which client sends the control command and the storage server copies data without passing through the data between the client and storage server. Compared with traditional copy operations, data is read from the source storage server and then written to the target storage server after two network transmissions. Data transmission on the network is reduced, and bandwidth resources are greatly released. In addition, the client changes from an original data copy executor to a data copy controller, and a specific execution action is executed by the storage server. Therefore, a large amount of computing resources and memory resources are saved on the client side. "OpenPGP Hardware-Backed Secret Keys", Daniel Gillmor, 2023-12-28, This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored on a hardware device. "Adding a Wrong Recipient URL for Handling Misdirected Emails", David Weekly, 2024-02-16, This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dweekly.github.io/ietf-wrong-recipient/draft-dweekly-wrong- recipient.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/. Source for this draft and an issue tracker can be found at https://github.com/dweekly/ietf-wrong-recipient. "Guidelines for Charactering "OAM"", Carlos Pignataro, Adrian Farrel, 2024-01-20, 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 acronym. 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 acronym, 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". "OpenPGP Literal Data Metadata Integrity", Andrew Gallagher, 2024-01-01, This document specifies a method for ensuring the integrity of file metadata when signed using OpenPGP. "A lightweight DNS delegation confirmation protocol", Peng Zuo, Zhiwei Yan, 2024-01-01, Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. "A lightweight DNS delegation confirmation protocol", Peng Zuo, Zhiwei Yan, 2024-01-01, Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. "RDAP Extension for DNS Time-To-Live (TTL Values)", Gavin Brown, 2024-01-02, 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. "Simplemux Blast flavor", Jose Saldana, 2024-01-02, Many utilities are nowadays connected via dedicated networks, but the trend toward a fully IP network is gaining more traction in some sectors (e.g. electric power). In some use cases, although it would be desirable to avoid the use of IP networks, this may prove unavoidable. Consequently, equipment is linked to extensive communication networks, the performance of which cannot be fully controlled or known. Some utilities that are not connected to a dedicated network may use public wireless networks, which present certain degree of variability of some parameters (delay, jitter, packet loss, and bandwidth limits). Considering the importance of receiving packets with a low delay, this document presents a solution for using tunnels to send frames or packets between remote facilities, with a certain degree of redundance. This can be useful in some use cases as e.g. the sending of event-driven field commands between eletric substations. In some cases, these messages can be very critical, and their loss or delay can make the difference between a blackout and a simple outage. Considering the high redundancy of the protocol, its use must be restricted to traffic flows which require very low delay to control critical equipment. "Cryptovolense", Orie Steele, 2024-01-02, Digital presentations enable a holder of digital credentials to present proofs to a verifier. Using QR Codes for digital presentations introduces challenges regarding maximum transmission size, error correction and confidentiality. This document describes a generic optical transmission protocol suitable for digital credential presentations. "WebTransport over WebSocket", Marten Richter, 2024-01-03, 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]. "Extended Key Update for Transport Layer Security (TLS) 1.3", Hannes Tschofenig, Michael Tuexen, Tirumaleswar Reddy.K, Steffen Fries, 2024-03-03, The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs)", Hannes Tschofenig, Brendan Moran, 2024-01-04, 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, 2024-01-05, This document proposes a 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. "Clarification to processing Key Usage values during CRL validation", Corey Bonnell, Tadahiko Ito, Tomofumi Okubo, 2024-01-05, 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, there is no requirement for validators to verify the presence of the keyUsage extension itself. The lack of this requirement may manifest in an issue in some Public Key Infrastructures where a CRL issuer who has been certified by a Certification Authority to issue CRLs on its behalf can sign CRLs using a key that has not been certified for signing CRLs. This document specifies an enhancement to the CRL validation process to explicitly require the presence of the keyUsage extension to resolve this issue. "SADCDN Video Optimization Requirements", Matt Joras, Anoop Tomar, Abhishek Tiwari, Alan Frindell, 2024-01-05, These are the requirements for the "Video Optimization" use-case for the SADCDN 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. 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/mjoras/sadcdn-video-optimization-requirements. "SPICE Metadata Discovery", Orie Steele, 2024-01-22, Entities interested in digital credentials need to express and discover preferences for working with them. Before issuance, holders need to discover what credentials are supported, and issuers need to discover if a holder's wallet is safe enough to store their credentials. Before presentation, holder's need to discovery verifier's encryption keys, and which presentation formats a verifier supports. After presentation, verifiers need to discover any new key material or status changes related to credentials. This document enables issuers, holders and verifiers to discover supported protocols and formats for keys, claims, credentials and proofs. "Transparency Tokens", Orie Steele, 2024-01-07, When professionals travel for business, they carry identity documents, such as passports, employer related payment capabilites, such as corporate credit cards, and security keys that might be used for both personal or professional reasons, such as hotel or car keys. These credentials might be stored in a purse, briefcase or wallet. Digital storage systems struggle to support the various credential formats, physical proximity and remote presentation protocols, and assurance capabilities needed to enable international business. Device capabilities, cost and power consumption can preclude access and adoption of digital credentials, or exclude communities that require higher than normal privacy, sustainability, or availability guarantees. This specification describes a scalable solution to digital credentials, that is market friendly, transport agnostic, privacy oriented, and accountable to users of digital credentials above all other stakeholders. "AAA for Hierarchical Network Slices", Xiaoqiu Zhang, Changwang Lin, Yuanxiang Qiu, 2024-01-07, This document describes an enhanced AAA mechanism for hierarchical network slice service when users access to the network and use the network slice resources of different SLA levels. "Intra-domain SAV Support via IGP", Weiqiang Cheng, Dan Li, Changwang Lin, 1211176911910469110103, 2024-02-25, This document describes a Dynamic calculation SAVNET mechanism by extending IGP protocol in intra-domain scenarios. This mechanism can propagate SAV-related information through IGP messages to help routers automatically generate accurate SAV rules which are for checking the validity of data packets. "Internet Wall", pradeep xplorer, 2024-01-09, To have a way to specify an URL that can retrieve contents that is available only after authentication "Explicit Forged Answer Signal", Pan Lanlan, 2024-01-10, This document describes that recursive resolver should give explict signal in the forged answer. Client could react more clearly based on the explict forged answer signal, to protect user on security and privacy. "X-Wing: general-purpose hybrid post-quantum KEM", Deirdre Connolly, Peter Schwabe, Bas Westerbaan, 2024-01-23, 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", Dan Li, Lancheng Qin, Li Chen, Libin Liu, 2024-01-10, The primary design goal of source address validation (SAV) is avoiding improper block (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 typically generate ingress SAV allowlist filters by using information related to customer cone. This document analyzes potential improper block problems of solely using allowlist filters. To minimize improper block, this document proposes Bicone SAV, which enhances the SAV technology by additionally using blocklist filters generated based on information related to provider cone. "Blind BBS Signatures", Vasilis Kalos, Greg Bernstein, 2024-01-11, 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. Source for this draft and an issue tracker can be found at https://github.com/BasileiosKal/blind-bbs-signatures. "Transfer Digital Credentials Securely", Dmitry Vinokurov, Yogesh Karandikar, Matthias Lerch, Alex Pelletier, Nick Sha, 2024-01-11, Digital Credentials allow users to access Homes, Cars or Hotels using their mobile devices. Once a user has a Credential on a device, sharing it to others is a natural use case. Process of sharing credentials should be secure, privacy preserving and have a seamless user experience. To facilitate Credential sharing, a new transport is required. This document defines that new transport to meet unique requirements of sharing a Credential. "Oblivious Credential State", Orie Steele, 2024-01-13, Issuers of Digital Credentials enable dynamic state or status checks through the use of dereferenceable identifiers, that resolve to resources providing herd privacy. Privacy in such systems is determined not just from the size of the herd, and the cryptographic structure encoding it, but also from the observability of access to shared state. This document describes a privacy preserving state management system for digital credentials based on Oblivious HTTP that addresses both data model and protocol risks associated with digital credentials with dynamic state. "Support of Network Observation Timestamping in YANG Notifications", Thomas Graf, Benoit Claise, Alex Feng, 2024-01-14, This document extends the YANG Notification header with the YANG objects observation timestamping, both for the "push-update" and "push-change-update" notifications. "How is the Area Director Workload Made Up?", Adrian Farrel, Rich Salz, 2024-01-15, Anecdotally, every IESG complains about the Area Director (AD) workload, and says that it takes the first full term to understand the job. Empirically, the AD workload is high sometimes causing backlogs in processing of Internet-Drafts and stressing the ADs. After some discussions in the GENDISPATCH working group and arising from an Internet-Draft postulating changes that might reduce the AD workload, several ADs reported some data on how they spent their time in a few weeks chosen at random. This document collates that data and presents it for information. This document does not attempt to draw any conclusions from the limited data currently available, and there is no intention to publish this document as an RFC. "Entering IPv6 Zone Identifiers in User Interfaces", Brian Carpenter, Robert Hinden, 2024-02-29, 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. 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/). "XML to JSON conversion rules for RESTful EPP", Maarten Wullink, Marco Davids, 2024-01-16, This document describes the rules for converting an EPP [RFC5730] XML message to a JSON [RFC8259] message for use with RESTful EPP [REF-TO- REPP-HERE]. "Dataplane Enhancement Taxonomy", Jinoo Joung, Xuesong Geng, Shaofu Peng, Toerless Eckert, 2024-02-25, 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 briefly mentioned. "JOSE algorithms for ECDH-MAC-based signatures", Paul Bastian, 2024-01-17, This specification defines a JSON Web Algorithm for JOSE, that uses a combination of key agreement and MAC to construct a signature-like mechanism. "Peering API", Carlos Aguado, Matt Griswold, Jenny Ramseyer, Arturo Servin, Tom Strickx, 2024-03-16, We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. "Paths Limit for Multiple Paths in BGP", Donatas Abraitis, Alvaro Retana, Jeffrey Haas, 2024-02-01, 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. "Email identity", pradeep xplorer, 2024-01-30, To have a way in PHP and html to get the email identities and phone numbers that logged into the client IP address that viewed a wevsite "Policing Caused Jitter Control Mechanism", Shaofu Peng, Peng Liu, Kashinath Basu, 2024-01-18, A mechanism to eliminate jitter caused by policing delay is described. It needs to be used in combination with a scheduling mechanism that provides low jitter for the transport path, and ultimately provides a low jitter guarantee for the application flow. "Delay Options", Shaofu Peng, 2024-01-18, This document introduces new IPv6 options for HBH or DOH Options header, to carry delay related information for deterministic forwarding. "Some Key Terms for Incident Management", Nigel Davis, Adrian Farrel, 2024-01-18, This document sets out some key terms that are fundamental to a common understanding of Incident Management. The purpose of this document is to bring clarity to discussions and other work related to Incident Management in particular YANG models and management protocols that report, make visible, or manage incidents. "Safe(r) Limited Domains", Warren Kumari, Andrew Alston, Eric Vyncke, Suresh Krishnan, 2024-01-19, There is a trend towards documents describing protocols that are only intended to be used within "limited domains". Unfortunately, these drafts often do not clearly define how the boundary of the limited domain is established and enforced, or require that operators of these limited domains //perfectly// implement filters to protect the rest of the Internet from these protocols. In addition, these protocols sometimes require that networks that are outside of (and unaffiliated with) the limited domain explicitly implement filters in order to protect their networks if these protocols leak outside of the limited domain. This document discusses the concepts of "fail-open" versus "fail- closed" protocols and limited domains, and provides a mechanism for designing limited domain protocols that are safer to deploy. "Semantic Metadata Annotation for Network Anomaly Detection", Thomas Graf, Wanting Du, Alex Feng, Vincenzo Riccobene, Antonio Roberto, 2024-03-16, This document explains why and how semantic metadata annotation helps to test, validate and compare outlier detection, supports supervised and semi-supervised machine learning development, enables data exchange among network operators, vendors and academia and make anomalies for humans apprehensible. The proposed semantics uniforms the network anomaly data exchange between and among operators and vendors to improve their network outlier detection systems. "IPv4 routes with an IPv6 next hop", Juliusz Chroboczek, Warren Kumari, Toke Hoeiland-Joergensen, 2024-01-21, We propose "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. We describe the technique, and discuss its operational implications. { Editor note: This document was originally published as draft- chroboczek-int-v4-via-v6, and later renamed to draft-chroboczek- intarea-v4-via-v6 . } "The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO", Ziyang Xing, Xiaoqiang Di, Hui Qi, 2024-01-22, This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, 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, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. "Extensible Delegation for DNS", Tim April, Petr Spacek, Ralf Weber, tale, 2024-01-23, 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, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. "MPLS FRR bypass path calculation with bandwidth awareness without reservation", Rafal Szarecki, Jon Mitchell, 2024-01-23, RFC4090 documents facility backup FRR in MPLS-TE networks. This document describes methods that allow the Point of Local Repair (PLR) to find a path with sufficient available bandwidth to accommodate protected traffic, while not making undesired reservations that would require additional capacity. Below aspects are covered: * Automatic determination of bypass required bandwidth by the PLR * Calculation of path based on this information using constrained shortest path algorithm (CSPF) * Determination of RSVP SENDER-TSPEC rate value for bypass tunnel signaling "Intent Translation Engine for Intent-Based Networking", Pedro Martinez-Julia, Jaehoon Jeong, 2024-03-04, This document specifies the schemas and models required to realize the data formats and interfaces for Intent-Based Networking (IBN). They are needed to enable the composition of services to build a translation engine for IBN-based network management. This intent translation engine (called an intent translator) is an essential function for network intents to be enforced into a target network for the configuration and management of the network and its security. "Extensible Provisioning Protocol (EPP) mapping for DELEG records", Gavin Brown, Paul Hoffman, 2024-01-26, This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names. 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/epp-deleg-extension. "Asset Schema Architecture for Asset Exchange", Denis Avrilionis, Thomas Hardjono, 2024-03-18, 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. "Use Cases-Standalone Service ID in Routing Network", Daniel Huang, gechen, Jie Liang, Yan Zhang, Feng Yang, Dong Yang, Dongyu Yuan, FUHUAKAI, Cheng Huang, Yong Guo, 2024-01-28, More and more emerging applications have raised the demand for establishing networking connections anywhere and anytime, alongside the availability of highly distributive any-cloud services. Such a demand motivates the need to efficiently interconnect heterogeneous entities, e.g., different domains of network and cloud owned by different providers, with the goal of reducing cost, e.g., overheads and end-to-end latency, while ensuring the overall performance satisfies the requirements of the applications. Considering that different network domains and cloud providers may adopt different types of technologies, the key of interconnection and efficient coordination is to employ a unified interface that can be understood by heterogeneous parties which could derive the consistent requirements of the same service and treat the service traffic appropriately by their proprietary policies and technologies. This document provides use cases and problem statements from two main Internet traffic categories: one is the traditional north-south traffic which is defined from clients to entities (such as servers or DCs), and the other is east-west traffic which refers to traffic between entities (such as inter-server or inter-service).The requirements for a standalone Service ID are also derived. "Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)", Yanfei Guo, Liang Xia, Yu Fu, 2024-01-28, This document defines a set of cryptographic transforms for using in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on 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 are mandatory 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. "RPKI Manifest Number Handling", Tom Harrison, George Michaelson, Job Snijders, 2024-03-04, 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. "Export of GTP-U Information in IP Flow Information Export (IPFIX)", Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Benoit Claise, Vyasraj Satyanarayana, 2024-03-16, This document introduces IP Flow Information Export Information Elements to identify 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. "Detecting RRDP Session Desynchronization", Job Snijders, Ties de Kock, 2024-02-14, This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover, as implemented in OpenBSD's rpki-client validator and Mikhail Puzanov's rpki-prover. "JSON Schema extension to NTV data", Philippe Thomy, 2024-02-01, The NTV format is an extension of the JSON format integrating a semantic dimension through the notion of type. This format remains compatible with the current JSON format but it is relevant to examine its compatibility and its impacts with data schemas. This document provides some answers to this question and presents some of the possible developments based mainly on the example of JSON Schema and additionally on the example of OpenAPI. "Transport Layer Security (TLS) Authentication with Verifiable Credential (VC)", Andrea Vesco, Leonardo Perugini, 2024-02-16, This document defines a new certificate type and extension for the exchange of Verifiable Credentials in the handshake of the Transport Layer Security (TLS) protocol. The new certificate type is intended to add the Verifiable Credentials as a new means of authentication. The resulting authentication process leverages a distributed ledger as the root of trust of the TLS endpoints' public keys. The endpoints can use different distributed ledger technologies to store their public keys and to perform the TLS handshake. "DHCPv4 over DHCPv6 with Relay Agent Support", Claudio Porfiri, Suresh Krishnan, Jari Arkko, Mirja Kuehlewind, 2024-02-01, This document describes a general mechanism for networks with legacy IPv4 only clients to use DHCPv4-over-DHCPv6 (DHCP 4o6) for discovering information about network Topology. To address this scenario, this document specifies an amendment to RFC7341 that allows a new 4o6 Relay Agent (4o6RA) to perform the 4o6 DHCP en- and decapsultion instead of the client. "Deterministic Hashed Data Elision: Problem Statement and Areas of Work", Shannon Appelcline, Wolf McNally, Christopher Allen, 2024-02-01, This document discusses the privacy and human rights benefits of data minimization via the methodology of hashed data elision and how it can help protocols to fulfill the guidelines of RFC 6973: Privacy Considerations for Internet Protocols and RFC 8280: Research into Human Rights Protocol Considerations. Additional details discuss how the extant Gordian Envelope draft can provide further benefits in these categories. "PROBE: A Utility for Probing Interfaces", Bill Fenner, Ron Bonica, Reji Thomas, Jen Linkova, Chris Lenart, Mohamed Boucadair, 2024-02-01, 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. "A SOCKS Transparent Proxy Method", G. Lucioni, 2024-02-02, This document describes a backwards-compatible extension of the SOCKS version 5 protocol to include a transparent proxy type method. "TCP-AO Protection for BGP Monitoring Protocol (BMP)", Hemant Sharma, 2024-02-10, This document outlines the utilization of the Transmission Control Protocol - Authentication Option (TCP-AO), as prescribed in RFC5925, for the authentication of Border Gateway Protocol Monitoring Protocol (BMP) sessions, as specified in RFC7854. The intent is to heighten security within the underlying Transmission Control Protocol (TCP) transport layer, ensuring the authentication of BMP sessions established between routers and BMP stations. "ICMP Extensions for Environmental Information", Carlos Pignataro, Jainam Parikh, Ron Bonica, Michael Welzl, 2024-03-04, 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 impact 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- impact metrics. "Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes", Job Snijders, Tobias Fiebig, Massimiliano Stucchi, 2024-02-23, This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with attributes signaling validation state may flood needless BGP UPDATE messages through the global Internet routing system, when, for example, Route Origin Authorizations are issued, revoked, or RPKI-To- Router sessions are terminated. Operators SHOULD ensure Validation States are not signalled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into distinct BGP Communities. "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers", Rakesh Gandhi, Tianran Zhou, 2024-02-06, Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields defined in RFC 9197 can be used for recording and collecting Hop-By-Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect any IPv6 options and MPLS Network Action Sub-Stacks for hop-by-hop and edge-to-edge active measurements, including IOAM data fields. "OAuth 2.0 Nonce Endpoint", Giuseppe De Marco, Orie Steele, 2024-02-06, This document defines the Nonce Endpoint for OAuth 2.0 implementations [RFC6749]. It details how an Authorization Server generates and issues opaque Nonces and how a client can learn about this endpoint to obtain a Nonce generated by the Authorization Server. "OAuth Status Attestations", Giuseppe De Marco, Orie Steele, Francesco Marino, 2024-02-06, Status Attestation is a signed object that demonstrates the validity status of a digital credential. These attestations are ephemeral and periodically provided to holders, who can present these to Verifiers along with the corresponding digital credentials. The approach outlined in this document makes the verifiers able to check the non- revocation of a digital credential without requiring to query any third-party entities. "RTCP feedback Message Timing Configuration", Shridhar Majali, 2024-02-06, This specification describes configuring the Real-time Transport Control Protocol (RTCP) message feedback send time. "IPv6 Address Assignment for SRv6", Yisong Liu, Yongqing Zhu, 2024-02-07, This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios. "A Network Inventory Location Model", Bo Wu, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Phil Bedard, 2024-02-07, This document defines a Yang data model for Network Inventory location, e.g. site, room, rack, geo-location data, which is used to provide location information with different granularities for network inventory items (such as Network Elements, device components). Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from Network Elements and therefore is not included in the base Network Inventory model defined in draft-ietf- ivy-network-inventory-yang. The purpose of this document is to define a location model for network inventory that extends the base inventory with comprehensive location data. "NASR Use Case and Requirements", Peter Liu, Luigi Iannone, Diego Lopez, Antonio Pastor, Meiling Chen, Li Su, 2024-03-03, This document describes the use cases and requirements that guide the specification of a Network Attestation for Secure Routing framework (NASR). "MASQUE extension for signaling media bitrate", Marcus Ihlar, Mirja Kuehlewind, 2024-02-09, 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 the available bitrate for media traffic that is proxied through an HTTP server. This information can be used by a media application to regulate its media bitrate in accordance with a network policy, as an alternative to in-network traffic shaping. "Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers", Job Snijders, Stavros Konstantaras, Mo Shivji, 2024-03-16, 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. "Security and Privacy Implications of 3GPP AI/ML Networking Studies for 6G", Behcet Sarikaya, Roland Schott, 2024-02-09, This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) networking. 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. "Extending ICMP for System Identification", Bill Fenner, 2024-02-09, 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 each 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 or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). "Something Better Than Errata", Stephen Farrell, 2024-02-11, This document outlines some ideas for a system 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. "Just-In-Time RFC Publication", Eric Rescorla, 2024-02-11, This document describes a new approach to RFC publication that is intended to allow easy revisions without re-running the entire RFC publication process. 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/ekr/draft-rescorla-rfc-jit. "Policy Considerations for Changes to RFCs", Brian Carpenter, 2024-02-23, This document describes policies applicable when the text of an RFC is modified after it has been approved for publication. 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-carpenter-rswg-rfc-changes/. Discussion of this document takes place on the RSWG Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. "The "testing" flag for Service Binding (SVCB) Records", Benjamin Schwartz, Manu Bretelle, 2024-02-12, This draft defines a flag to mark a service endpoint as being potentially unreliable. This flag may be useful when introducing new features that could have a negative impact on availability. 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-manuben-svcb-testing-flag/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/svcb-testing-flag. "Characterization and Benchmarking Methodology for Power in Networking Devices", Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, 2024-03-04, 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, 2024-02-14, Complex telephony networks using SIP as signalling like the IP Multimedia Subsystem (IMS) of the Third Generation Partnership (3GPP) serving different groups of customers like business and retail customers with different products like mobile, fixed and PBX 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. "Discovery of CIDFI-aware Network Elements", Dan Wing, Tirumaleswar Reddy.K, Mohamed Boucadair, 2024-02-14, Host-to-network signaling and network-to-host signaling can improve the user experience to adapt to network's constraints and share expected application needs, and thus to provide differentiated service to a flow and to packets within a flow. The differentiated service may be provided at the network (e.g., packet prioritization), the server (e.g., adaptive transmission), or both. Such an approach is called CIDFI, for Collaborative and Interoperable Dissemination of Flow Indicators. A key component in a CIDFI system is to discover whether a network is CIDFI-capable, and if so discover a set of CIDFI-aware Network Elements (CNEs) that will be involved in the Host-to-network signaling and network-to-host signaling. This document discusses a set of discovery methods. "A YANG Data Model for Energy Saving Management", CHENGEN, Qin WU, Mohamed Boucadair, Oscar de Dios, Carlos Pignataro, 2024-03-02, This document defines a YANG module for power and energy management. The document covers both device and network levels. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Inventory YANG Working Group mailing list (inventory-yang@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/inventory-yang/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-cwbgp-energy-saving-management. "Auto-discovery mechanism for ACME authorized clients", Paul van Brouwershaven, Mike Ounsworth, Corey Bonnell, Inigo Barreira, Q Misell, 2024-02-15, A significant challenge in the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is the trust establishment between ACME servers and clients. While ACME clients can automatically discover the URL of the ACME server through ACME Auto Discovery [I-D.vanbrouwershaven-acme-auto-discovery], they face difficulty in identifying authorized clients. This draft proposes a solution to this problem by allowing Certification Authority (CA) customers to specify which ACME keys are authorized to request certificates on their behalf by simply providing the domain name of the service provider. Specifically, this document registers the URI "/.well-known/acme- keys" at which all compliant service providers can publish their ACME client public keys. This mechanism allows the ACME server to identify the specific service provider, enhancing the trust relationship. Furthermore, it provides flexibility to service providers as they can use multiple keys and rotate them as often as they like, thereby improving security and control over their ACME client configurations while giving CA customers the ability to specifically authorize which service providers can request certificates on their behalf. "IPv4 Parcels and Advanced Jumbos (AJs)", Fred Templin, 2024-02-19, IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs and a new link model for Internetworking. 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. "QUIC on Streams", Kazuho Oku, Lucas Pardue, 2024-02-16, This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. 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/kazuho/draft-kazuho-quic-quic-on-streams. "HTTP/3 on Streams", Kazuho Oku, Lucas Pardue, 2024-02-16, This document specifies how to use HTTP/3 on top of bi-directional, byte-oriented streams such as TLS over TCP. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. "IPv6 Parcels and Advanced Jumbos (AJs)", Fred Templin, 2024-02-19, 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 only 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 significant 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 Network (DTN) link model. "Automatic Extended Route Optimization (AERO)", Fred Templin, 2024-02-22, This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) interfaces. AERO/OMNI use an IPv6 unique-local address format for IPv6 Neighbor Discovery (IPv6 ND) 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. AERO is a widely-applicable mobile internetworking 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. "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, 2024-02-22, 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 deployments such as enterprise and home networks. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. "OAuth Cookie Response Mode", Jared Hanson, 2024-02-16, This specification defines a response mode for OAuth 2.0 that uses a cookie to obtain and transmit an access token. In this mode, the access token is encoded using an HTTP Set-Cookie header and transmitted via the HTTP Cookie header to the client or resource server. "The Computing-Aware Routing Architecture in Computing-Aware Traffic Steering", Tianhao Peng, Yuyin Ma, 2024-02-17, This document proposes a compute-aware routing (CAR) architecture for Computing-Aware Traffic Steering (CATS), designed to support routing systems with compute resource awareness and provide a standardized approach for network devices and services. "Lightweight Route Information Advertisement for LEO Mega-constellation", Hou Dongxu, Xiao Min, Fenlin Zhou, 2024-02-17, This document presents a lightweight route information advertisement method in satellite networks. On the one hand, the method selects the advertisement link by the way of route-associated judgment, to reduce the overhead of route information advertisement. On the other hand, the method provides a manner for dealing with link fault during the route information advertisement process, to ensure the reliability of routing information advertisement. "IGP Flexible Algorithm with Time Constraint", Jie Dong, Li Zhang, 2024-02-18, IGP Flexible Algorithm allows IGPs to compute constraint-based paths over the network using different types of metrics or constraints. This document defines a new type of constraint called "Time Constraint", which can be used to control the time period during which a Flex-Algorithm takes effect for constraint-based path calculation. Such mechanism may be useful in network scenarios where either the traffic demand or the characteristics of the network varies as a function of time. The procedures of using Time Constraint in Flexible Algorithm is also described. "Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms", Simon Josefsson, 2024-02-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 traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, Classic McEliece mceliece6688128f. "Signaling Aggregate Header Size Limit via IGP", Yao Liu, Yiming Shen, 2024-02-19, This document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node to for efficient packet processing. Aggregate header limit is the total header size(e.g, in IPv6, it includes the IPv6 header chain as well as any headers that are part of network encapsulation that precedes the innermost transport layer) that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. "Hash-based Signatures: State and Backup Management", Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis, 2024-02-19, 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. "Increase of the Congestion Window when the Sender Is Rate-Limited", Michael Welzl, Tom Henderson, Gorry Fairhurst, 2024-02-22, This document specifies how transport protocols increase their congestion window when the sender is rate-limited. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. "IPv6 Extended Fragment Header", Fred Templin, 2024-02-19, 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 that includes a 64-bit Identification; it further defines a control messaging service for fragment retransmission and reassembly congestion management. "IPv6 Extended Fragment Header for IPv4", Fred Templin, 2024-02-19, 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. "Identifying Email Forwarding", Wei Chuang, 2024-02-19, Forwarded email often becomes unauthenticated because it breaks SPF (RFC7208) authentication and DKIM (RFC6376) authentication. For example mailing-lists distribute email to multiple recipients through a separate server than the original sending server that breaks IP based SPF authentication and potentially may modify the message that breaks the DKIM signature. This document calls for using ARC (RFC8617) to identify and authenticate forwarded emails by further specifying the naming of the two digital signatures present in ARC headers- the message signature and the seal. Because this uses ARC digital signature, the receiver has confidence that a valid signature corresponding to some forwarder only could have been generated by the named domain. This document also specifies that all forwarded mail flows have associated ARC headers and the means to characterize the mail flows. "Reverse Tunnel over HTTP", Kazuho Oku, 2024-02-19, This document specifies an HTTP extension to establish bi-directional byte streams in the direction from servers to their clients, utilizing HTTP as a tunneling mechanism. This approach not only facilitates communication between servers located behind firewalls and their known clients but also introduces the potential for these known clients to serve as relays. In such configurations, clients can forward application protocol messages or relay TCP connections, allowing servers to interact with any client on the Internet without direct exposure. "Implementation and Performance Evaluation of PDM using eBPF", Nalini Elkins, Chinmaya Sharma, Amogh Umesh, Balajinaidu V, Mohit Tahiliani, 2024-02-20, 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 kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. "Implementation and Performance Evaluation of PDM using eBPF", Nalini Elkins, Chinmaya Sharma, Amogh Umesh, Balajinaidu V, Mohit Tahiliani, 2024-02-20, 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 kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. "Best Practices for Link-Local Connectivity in URI-Based Protocols", David Schinazi, 2024-02-22, Link-local IP connectivity allows hosts on the same network to communicate with each other without the need for centralized IP addressing infrastructure. The IP prefixes 169.254.0.0/16 and fe80::/10 were reserved for this purpose. However, both IP versions have limitations that make link-local addresses unideal for usage with URI-based protocols. This document provides guidance for how best to enable link-local connectivity in such protocols. This document also obsoletes RFC 6874, a previous attempt at solving this issue. "Stream Namespaces for QUIC", Victor Vasiliev, 2024-02-20, QUIC Stream Namespaces provide an extension to the QUIC protocol that enables multiplexing multiple logical groups of streams within the same connection, while providing flow control isolation. "Keep inter-domain forwarding conformance to routing", Weiqiang Cheng, 1211176911910469110103, Mingxing Liu, Mingqing(Michael) Huang, 2024-02-20, This document introduces what the conformance forwarding is and why nonconformance forwarding is prevalent in the Internet, describes the risks of nonconformance forwarding and defines the requiremenets for conformance forwarding. "Stand-in Tags for YANG-CBOR", Carsten Bormann, Maria Matejka, 2024-02-21, 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, 2024-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. "Cedar Profile for OAuth 2.0 Rich Authorization Requests", Sarah Cecchetti, 2024-02-21, This specification defines a profile of OAuth 2.0 Rich Authorization Requests in Cedar policy format within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to distribute and recieve relevant Cedar policy sets in an interoperable manner. "A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET", Li Chen, Libin Liu, Dan Li, Lancheng Qin, 2024-02-22, 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. "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA", Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis, 2024-02-22, Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-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. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 205 Stateless Hash-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS", Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis, 2024-02-22, This document specifies algorithm identifiers and ASN.1 encoding formats for the Stateful Hash-Based Signature Schemes (S-HBS) 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. "Greasing Protocol Extension Points in the DNS", Shumon Huque, Mark Andrews, 2024-02-29, 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/shuque/ietf-dns-grease. "Path-aware Remote Protection Framework", Yisong Liu, Changwang Lin, Mengxiao Chen, Zheng Zhang, 2024-03-03, This document describes the framework of path-aware remote protection. "Routing Consideration for Satellite Constellation Network", Tianji Jiang, Peng Liu, Huaimo Chen, 2024-02-23, The 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on a 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 somewhat significant work to be explored in the IETF domain. This draft stems from the latest 3GPP satellite use cases, and lands on summarizing the restrictions & challenges in term of satellite-based routing. Based on some unique & advantageous characteristics associated with satellite movement, the draft raises briefly the general design principles and possible algorithms for the integrated NTN+TN routing, while leaves the implementation details for further expansion. "FC-BGP Protocol Specification", Ke Xu, Xiaoliang Wang, Zhuotao liu, Li Qi, Jianping Wu, Yangfei Guo, 2024-02-23, This document describes Forwarding Commitment BGP (FC-BGP), an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. Forwarding Commitment(FC)is a cryptographically signed code 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 BGP UPDATE and validate network forwarding on the data plane. "An Architecture for YANG-Push to Apache Kafka Integration", Thomas Graf, Ahmed Elhassany, 2024-03-16, This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into Apache Kafka Message Broker and YANG Schema Registry. "A YANG Data Model for Network Incident Management", Tong Hu, Luis Contreras, Thomas Graf, Zhenqiang Li, Qin WU, Chaode Yu, Nigel Davis, Chong Feng, 2024-03-02, 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 few amount of network incidents by data correlation analysis and the service impact analysis. This document defines YANG Modules for the network incident lifecycle management. The YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of network service health and root cause analysis. "The need for email archival option in email clients", pradeep xplorer, 2024-02-24, This document describes the need for a email archive option button or check box in email client to make sure of accountability of emails, transmission delivery and control of email SPAM "Advertisement of SR Policy Flexible Candidate Path Selection Result using BGP Link-State", Yisong Liu, Changwang Lin, Yuanxiang Qiu, 2024-02-25, This document defines the extension of BGP Link-State to advertise the result of SR Policy flexible candidate path selection. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. "Addition of New BMP Stat Types", Yisong Liu, Changwang Lin, Jinming Li, 2024-02-25, BMP statistics messages are used by the monitoring station to observe interesting events that occur on the router. Several BMP statistics types are defined in RFC 7854, this document lists some new statistics types to update RFC 7854 for growing BGP features. "Policy Considerations for Changes to RFCs", Brian Carpenter, 2024-02-25, This document clarifies the policy framework for changes to RFC formats and associated tool chains. 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-carpenter-rswg-format- details/. Discussion of this document takes place on the RSWG Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. "A Profile for Mapping Origin Authorizations (MOAs)", Chongfeng Xie, Guozhen Dong, Xing Li, 2024-03-01, For the authenticity of the mapping origin of IPv4 address block in IPv6-only networks, this document defines a standard profile for Mapping Origin Authorizations (MOAs). MOA is a cryptographically signed object that provides a means of verifying that the holder of a set of IPv4 prefixes has authorized an IPv6 mapping prefix to originate mapping for those prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. "Terminology and Use cases for Secured Routing Infrastructure", Michael Richardson, Peter Liu, 2024-02-26, This document collects terminology and use cases for Secured Routing. "Enhancing Route Origin Validation by Aggregating Validated ROA Payloads", Jia Zhang, Mingwei Xu, Yangyang Wang, 2024-02-26, 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, 2024-02-26, Privacy and accountability are currently significant concerns on the internet. Privacy generally implies untraceable sources. Effective verification methods inherently raise privacy concerns when confirming a user's identity. To prevent extensive modifications to current network protocols and the introduction of new identifiers, we propose an IPv6 based address label terminal identity authentication mechanism. This mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document outlines the implementation of address label authentication in the IPv6 extension header. "EAT Measured Component", Simon Frost, Thomas Fossati, Hannes Tschofenig, 2024-03-03, This document defines a "measured components" format that can be used with the EAT Measurements claim. "Remove ECC-GOST from active use within DNSSEC", Wes Hardaker, Warren Kumari, 2024-02-27, This document retires the use of ECC-GOST within DNSSEC. "An In Situ Operations, Administration, and Maintenance (IOAM) Multi-path Flag", Li Zhang, Tianran Zhou, 2024-02-28, 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 can promote the information collection and topology restoration of a multi-path topology. "RoCEv2-based Collective Communication Offloading", liufeng, Weifeng Wang, Rubing Liu, Yan Mu, Kehan Yao, 2024-02-28, This draft proposes the design scheme of RoCEv2-based collective communication offloading. Through establishing RDMA connections between client and switch, collective operations can be implemented on network nodes, thus improving the overall efficiency of collective communication. "IP Payload Compression excluding transport layer", Cheng Li, Hang Shi, Meng Zhang, Xiaobo Ding, 2024-02-28, 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. "Secure shell over HTTP/3 connections", Francois Michel, Olivier Bonaventure, 2024-02-28, The secure shell (SSH) traditionally offers its secure services over an insecure network using the TCP transport protocol. This document defines mechanisms to run the SSH protocol over HTTP/3 using Extended CONNECT. Running SSH over HTTP/3 enables additional benefits such as the scalability offered by HTTP multiplexing, relying on TLS for secure channel establishment leveraging X.509 certificates, HTTP Authentication schemes for client and server authentication, UDP port forwarding and stronger resilience against packet injection attacks and middlebox interference. "Problem Statement with Aggregate Header Limit", Yao Liu, Yisong Liu, 2024-02-28, Aggregate header limit(AHL) is the total header size that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. This document describes the problems for path calculation and function enablement without the awareness of AHL in SRv6, and the considerations for AHL collection are also included. "Implementation and Performance Evaluation of PDM using eBPF", Nalini Elkins, Chinmaya Sharma, Amogh Umesh, Balajinaidu V, Mohit Tahiliani, 2024-02-28, 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 kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. "Experiment: Network Anomaly Lifecycle", Vincenzo Riccobene, Antonio Roberto, Thomas Graf, Wanting Du, Alex Feng, 2024-03-16, Accurately detect network anomalies 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 specific service provided to consumers, apart from a proper monitoring infrastructure. In order to facilitate the detection of network anomalies, novel techniques are being introduced, including AI-based ones, 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. This document describes the lifecycle process to iteratively improve network anomaly detection accurately. Three key stages are proposed, along with a YANG model specifying the required metadata for the network anomaly detection covering the different stages of the lifecycle. "A SAVI Solution for IP based Satellite Access", Jun Liu, Hewu Li, Tianyu Zhang, Qian Wu, 2024-02-28, This document presents the source address validation solution for for IP based Satellite Access. This mechanism transfers user states through end network collaboration to solve the impact of dynamic handover of satellite-ground links on native SAVI. This document mainly describes the operations involved in overcoming the dynamics of the access link. "Segment Routing over IPv6 (SRv6) Proof of Transit", Luigi Iannone, Antoine Fressancourt, 2024-02-28, Various technologies, including SRv6, allow to perform Traffic Engineering (TE), steering IP traffic through a specific path. However, there is no native mechanism in IP that allows to verify whether or not a packet did follow the path it was supposed to. This document specifies a new TLV for the Segment Routing Header (SRH) that allows to provide a cryptographically generated proof of transit over the different segments. The proposed mechanisms allows to verify whether a packet did go through the segments listed in its SRH header in the intended order. "A Path Verification Solution based on SRv6", Jun Liu, Hewu Li, Tianyu Zhang, Qian Wu, Zongpeng Du, 2024-02-28, A trusted network path is desired for source authentication and path verification. The emergence of IPv6 Segment Routing (SRv6) may bring the opportunity to assemble trusted network paths with a lightweight IP header. This document describes a trusted network path verification mechanism based on SRv6 (Segment Routing to enable Trusted and Private Network Paths, SR-TPP), which supports network path verification with path information protection. SR-TPP extends SRv6 function in protocol header to meet the requirement of path compliance. Path information is sequentially encoded into the segment list in SR-TPP so that path information is partially visible to each intermediate router. The distributed verification of SR-TPP also makes it easier to locate faults. "ML-KEM for HPKE", Deirdre Connolly, 2024-02-28, This memo defines the ML-KEM-768-based and ML-KEM-1024-based ciphersuites for HPKE (RFC9180). ML-KEM is believed to be secure even against adversaries who possess a quantum computer. "On-time Forwarding with Push-In First-Out (PIFO) queue", Yeoncheol Ryoo, 2024-02-28, 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. "A YANG Data Model for the Alternate Marking Method", Thomas Graf, Minxue Wang, Giuseppe Fioccola, Tianran Zhou, Xiao Min, Guo Jun, Massimo Nilo, Liuyan Han, 2024-03-04, 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. "Intelligent Protection Optimization System for IOT", Xinru Li, Yuyin Ma, Guangshuo Chen, 2024-02-29, Communication technology is becoming more and more developed, the Internet of Things coverage is becoming more and more comprehensive, and a large number of data and devices are joining, which also makes more data security and privacy issues appear. Therefore, this draft proposes a scheme to build an information-centered network. By analyzing common network attack methods, an intelligent protection optimization system is established from three aspects: naming and parsing, data exchange, and data caching, so as to achieve better content privacy protection without adding additional costs. "BGP AS_PATH Validation State Extended Community", Tianhao Wu, Jun Ge, Xiangfeng Ding, Haibo Wang, 2024-02-29, This document defines a new BGP opaque extended community to carry the AS_PATH validation state based on Autonomous System Provider Authorization (ASPA) inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process. "Destination-IP-Community Filter for BGP Flow Specification", Tianhao Wu, Jun Ge, Xiangfeng Ding, Haibo Wang, 2024-02-29, BGP Flowspec mechanism (BGP-FS) 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 community-level filtering. The match field is the community of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. "External References to Values in CBOR Diagnostic Notation (EDN)", Carsten Bormann, 2024-02-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. "ACLs within the NFSv4 Protocols", David Noveck, 2024-02-29, This document describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While their role 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. While the goals of the description are similar to that used in previous specficaion, the approach taken is substantally different, in that a core set of functionality, derived form the the now- withdrawn POSIX draft ACLs is the conceptual base of the feature set while extensions to that functionality are made available as OPTIONAL extensions to that core. 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 document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents such as RFCs 7530 and 8881, thereby updating RFC7530 and RFC8881. "Latency analysis of mobile transmission", Balazs Varga, Joachim Sachs, Frank Duerr, Samie Mostafavi, 2024-02-29, 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, 2024-02-29, 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. "BGP-MVPN Source Active Route Enhancement", Zhaohui Zhang, Rishabh Parekh, 2024-02-29, RFC6514 specifies the protocol and procedures for multicast in MPLS/ BGP IP VPNs. In the Any-Source Multicast (ASM) case, the section "14. Supporting PIM-SM without Inter-Site Shared C-Trees" specifies that the Provider Edge that serves as a customer Rendezvous Point or runs Multicast Source Discovery Protocol advertises Source Active (SA) routes for ASM flows when it discovers those flows. This document describes a situation where an optional enhancement to the advertisement of SA routes is desired and specifies the procedures. It updates RFC6514. "Triggering Unsolicited Router Advertisements Upon Configuration Changes", Jen Linkova, 2024-02-29, IPv6 routers employ Router Advertisements (RAs) to disseminate essential network configuration data to hosts. RAs play a vital role in Stateless address autoconfiguration (SLAAC) and providing IPv6 connectivity. Timely updates via RAs become paramount as network configurations change to prevent service outages. This document modifies RFC4861, recommending immediate propagation of configuration information changes by routers. "Customer Experience Index for Evaluating Network Quality for Cloud Applications", Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Hongyi Huang, Tianran Zhou, 2024-02-29, 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. "The OID Directory: A Technical Roadmap", Jesse Coretta, 2024-02-29, This ID outlines a series of experimental standards documents which define the abstracts of the "OID Directory": a proposed philosophy and set of procedures used to facilitate the storage and management of the "OID spectrum" -- in part or in whole -- within an X.500/LDAP service implementation. "The OID Directory: The Schema", Jesse Coretta, 2024-02-29, In service to the "OID Directory" ID series, this ID declares schema definitions for use within an implementation of the Registration Authority Directory Information Tree. See the RADIR ID for a complete draft series manifest. "The OID Directory: The RA DUA", Jesse Coretta, 2024-02-29, In service to the "OID Directory" ID series, this ID covers design strategies, requirements and procedures for the client component of the OID Directory Registration Authority client/server model. See the RADIR ID for a complete draft series manifest. "The OID Directory: The RA DSA", Jesse Coretta, 2024-02-29, In service to the "OID Directory" ID series, this ID covers design considerations and basic requirements for the server component of the OID Directory Registration Authority client/server model. See the RADIR ID for a complete draft series manifest. "The OID Directory: The RA DIT", Jesse Coretta, 2024-02-29, In service to the "OID Directory" ID series, this ID covers design strategies and requirements relating to the Registration Authority Directory Information Tree. See the RADIR ID for a complete draft series manifest. "Deterministic Routing Header", Shaofu Peng, Ron Bonica, 2024-02-29, This document introduces a new IPv6 Routing Header used for deterministic forwarding wihch is generally a strict explicit path. This Routing Header will contain the decoupled topology instructions and deterministic forwarding resource indications. The target is low cost of encapasultion and less amount of allocated SIDs. "Anomalous Packets Handling for DetNet", Chang Liu, Jinjie Yan, Xiangyang Zhu, 2024-02-29, 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. "Gap Analysis of Online Data Express Service (ODES)", Guangyu Zhao, Hongwei Yang, Zongpeng Du, 2024-02-29, This document is a gap analysis of online data express delivery services, which is helpful to the design and development of online data express delivery services. "Trust-enhanced Path Routing: Problem Statement and Use Cases", Xiang Liu, Yanchen Qiao, Yu Zhang, 2024-02-29, Digital trust refers to the measurable confidence of one entity posts on another about accomplishing some task in the digital world. This document introduces the concept of trust into the networking and routing area, and proposes the idea of trust-enhanced path routing, elaborates the key technical problems and design goals, and also lists some use cases. "Procedures and Extension for VLAN-based Traffic Forwarding", Yue Wang, Aijun Wang, Boris Khasanov, Fengwei Qin, Huaimo Chen, Chun Zhu, 2024-03-01, This document defines the data plane operations around VLAN switching and describes a standard method for implementing VLAN tags, and thus the desired tag manipulation can be achieved. "Flow Aggregation for Enhanced DetNet", Quan Xiong, Tianji Jiang, Jinoo Joung, 2024-03-01, This document describes the flow aggregation scenarios and proposes a method by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet and the flow identification of aggregated-class can be used to indicate the required treatment and forwarding behaviors in scaling networks. "Extended YANG Data Model for DOTS", Yong Cui, Linzhe Li, 2024-03-01, With the development of DDoS defense technologies, the interfaces and parameters defined by DOTS are no longer sufficient to support the collaborative signaling required between DDoS mitigation systems. This document defines three YANG model to extend the data models of existing interfaces on the DOTS signaling and data channels, with the aim of supporting the transmission of necessary collaborative information between DDoS mitigation systems via DOTS and enabling efficient collaborative mitigation based on this information. "No Further Fast Reroute for SRv6 Service SID", Yisong Liu, Changwang Lin, Mengxiao Chen, Yao Liu, 2024-03-01, In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR flags for SRv6 Service SIDs in BGP messages. "SRv6 Service SID Anycast Flag", Yisong Liu, Changwang Lin, Mengxiao Chen, Yao Liu, 2024-03-01, 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, 2024-03-01, 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, 2024-03-01, 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. "Unrelated name server name requirement", Kazunori Fujiwara, 2024-03-01, Unrelated(out-of-bailiwick) name server names are required for DNS hosting services. However, using unrelated name server names increases the name resolution costs. This document proposes using in-domain name servers as much as possible for name resolution of unrelated name server names to reduce the name resolution costs. "Validating anydata in YANG Library context", Ahmed Elhassany, 2024-03-17, This document describes a method to use YANG Library [RFC8525] to validate YANG data nodes that are children of an "anydata" data node. "List Pagination Snapshots for YANG-driven Protocols", Per Andersson, Kent Watsen, Qin WU, Olof Hagsand, Hongwei Li, 2024-03-01, List pagination for YANG-driven protocols are defined in [I-D.ietf-netconf-list-pagination]. Operational data can have very large data sets. These data sets can furthermore have big churn, a lot of additions or deletions to the data set. In order to support a stable pagination of such data sets, snapshots can be used. This document defines snapshot support for pagination of "config false" nodes of type "list" and "leaf-list". The snapshot support for individual nodes is signaled via the "ietf-system-capabilities" module. "Advance Professional Video", Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi, 2024-03-01, 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, 2024-03-17, 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. "MKA over IP", Hooman Bidgoli, Nick Morris, Nabeel Cocker, 2024-03-01, Extensible Authentication Protocol (EAP) is described in [RFC3748]. EAP typically runs directly over data link layers such as Point-to- Point Protocol (PPP) or IEEE 802, without requiring IP. IEEE802.1X-2004 clarifies some aspect of the EAP over Layer 2 PDUs. IEEE802.1X-2010 introduces MACsec Key Agreement Protocol (MKA) which uses EAPOL. In IEEE 802.1X-2010 the existing EAPOL (EAP over LANs) PDU formats have not been modified, but additional EAPOL PDUs have been added to support MKA. MKA is used for discovering peers and their mutual authentication, to agree the secrete keys (SAKs) used by MACsec for symmetric shared key cryptography. This document describes procedures to transport EAP and ultimately MKA PDUs over a IP network to distribute SAKs for symmetric key cryptography. "Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications", Roland Schott, Michael Kreipl, Bastian Dreyer, Roland Jesske, 2024-03-01, This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active registrations. The concept can be mapped on any architecture having a distributed structure and could work for different protocols. The concept is exemplary explained here regarding an architecture for voice and is mapped on a 3GPP (3rd Generation Partnership Project) architecture. This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active UE (User Equipment) registrations on other Outbound Proxies (P-CSCF) within the SIP voice architecture. The AVORS concept increases service continuity, improves network resilience, and offers savings potential. Additionally, this document gives an outlook regarding stateless voice architectures, load calculation aspects, and Service Based Interfaces (SBI) in context data base interworking. Security aspects are considered in the security chapter. As stated above the AVORS principle is not only limited to the SIP protocol and could be adopted by other protocols. "Identity Assertion Authorization Grant", Aaron Parecki, Karl McGuinness, 2024-03-01, 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]. "Documenting and Managing DNSSEC Algorithm Lifecycles", Steve Crocker, Russ Housley, 2024-03-02, Cryptographic algorithms for DNSSEC go through multiple phases during their lifetime. They are created, tested, adopted, used, and deprecated over a period of time. This RFC defines these phases, and defines the criteria for moving from one phase to the next. "JOSE-COSE HPKE Cookbook", Orie Steele, 2024-03-02, This document contains a set of examples using JSON Object Signing and Encryption (JOSE), CBOR Object Signing and Encryption (COSE) and Hybrid Public Key Encryption (HPKE) to protect data. These examples are meant to coverage the edge cases of both JOSE and COSE, including different structures for single and multiple recipients, external additional authenticated data, and key derivation function (KDF) context binding. "Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE", Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig, 2024-03-16, 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-reddy-cose-jose-pqc/. Discussion of this document takes place on the cose Working Group mailing list (mailto:cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/cose/. "Use Cases and Problem Statement of Online Data Express Service", Zongpeng Du, Hongwei Yang, Guangyu Zhao, 2024-03-02, This document describes use cases and problem statement of Online Data Express Service. "SNMP Trap for SRv6 Policy", Ran Pang, Changwang Lin, Mengxiao Chen, 2024-03-03, This document defines the Simple Network Management Protocol (SNMP) trap module for SRv6 Policy. "Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives", Olga Havel, Benoit Claise, Oscar de Dios, Ahmed Elhassany, Thomas Graf, Mohamed Boucadair, 2024-03-03, This document shares experience in modelling Digital Map based on the IETF RFC 8345 topology YANG modules and some of its augmentations. First, the concept of Digital Map is defined and its connection to the Digital Twin is explained. Next to Digital Map requirements and use cases, the document identifies a set of open issues encountered during the modelling phases, the missing features in RFC 8345, and some perspectives on how to address them. 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/OlgaHuawei. "Vector Commitment-based Proof of Transit", Peter Liu, 2024-03-03, This document describes an ordered Proof of Transit mechanism. "IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method", Xiaoming He, Xiao Min, Frank Brockners, Giuseppe Fioccola, Chongfeng Xie, 2024-03-03, 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. "The UDP Authentication Option", Joseph Touch, 2024-03-03, This document extends UDP by defining a framework for an authentication option. "Telemetry Methodologies for Analog Measurement Instrumentation", Christopher Janz, Daniel King, 2024-03-03, Evolution toward network operations automation requires systems encompassing software-based analytics and decision-making. Network- based instrumentation provides crucial data for these components and processes. However, the proliferation of such instrumentation and the need to migrate the data it generates from the physical network to "off-the-network" software, poses challenges. In particular, analog measurement instrumentation, which generates time-continuous real number data, may generate significant data volumes. Methodologies for handling analog measurement instrumentation data will need to be identified and discussed, informed in part by consideration of requirements for the operation of network digital twins, which may be important software-realm consumers of such data. "YANG Model for IS-IS Segment Routing MPLS PICS", Yingzhen Qu, Les Ginsberg, Tony Przygienda, 2024-03-03, The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. "IKEv2 support for Child SA PFS policy notification", Paul Wouters, 2024-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 for the Perfect Forward Secrecy (PFS) and Key Exchange (KE) method setting of the initial Child SA. "YANG Data Models for Transport TE FGNM Extension Model", Chaode Yu, XingZhao, 2024-03-03, This document defines two extension YANG data models augmenting to TE topology and TE tunnel YANG model, based on the FGNM (Fine-Grain Network Management) requirements in transport networks. "Mobile User Plane Architecture for Distributed Mobility Management", Satoru Matsushima, Katsuhiro Horiba, Ashiq Khan, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Miya Kohno, Teppei Kamata, Pablo Camarillo, Jakub Horn, Dan Voyer, Shay Zadok, Israel Meilik, Ashutosh Agrawal, Kumaresh Perumal, 2024-03-03, 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 due to the DMM requirement, and is suitable for mobile services which require a large IP address space. "Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks", Hongyi Huang, Tao He, Tianran Zhou, 2024-03-03, This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, and audio/video production. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications. "Data Fields for Congestion Measurement", Hang Shi, Tianran Zhou, Zhenqiang Li, 2024-03-03, 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 arrive 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. "IGP Extensions for Source Prefix Identification", Dan Li, Lancheng Qin, Changwang Lin, 2024-03-03, This document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI. "IPv6 Options for Congestion Measurement", Hang Shi, Tianran Zhou, liuy619@chinaunicom.cn, Mengyao Han, 2024-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. "IOAM network awareness for Low Latency, Low Loss, and Scalable Throughput (L4S)", Wei Quan, Wei Su, Shuaihao Pan, Xiaobin Liang, Jie Liang, 2024-03-03, This specification defines a framework how to update L4S Dual-Queue Coupled AQM with In Situ Operations, Administration, and Maintenance (IOAM). These are designed for consistently very low queuing latency, very low congestion loss, and scaling of perflow throughput by using Explicit Congestion Notification (ECN) using the operational and telemetry information collected by IOAM. Since L4S lacks information about the use of network status and network nodes, which also affect network performance in practice, it is considered to use direct export mode for information collection of L4S-IOAM to strengthen the AQM regulation of L4S. It then gives the normative requirements that are necessary. "IKEv2 Support for Anti-Replay Status Notification", Wei Pan, Qi He, Paul Wouters, 2024-03-03, RFC 4302 and RFC 4303 specify that, during Security Association (SA) establishment, IPsec implementation should notify the peer if it will not provide anti-replay protection, to avoid having the peer do unnecessary sequence number monitoring and SA setup. This document defines the ANTI_REPLAY_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peers of their own anti-replay status when creating the IPsec SAs, to fulfill the above requirement. "Shared Use of IPsec Tunnel in a Multi-VPN Environment", Qi He, Wei Pan, Xiaolan Chen, Beijing Ding, 2024-03-03, In a multi-VPN environment, currently, different IPsec tunnels (i.e., different IKE SAs and Child SAs) have to be created to differentiate and protect the traffic of each VPN between the device and its peer. When the number of neighbors of a device and the number of VPNs increases, the number of IPsec tunnels also increases considerably. This results in the need for a large number of SAs, which exceeds the device's capacity. This document proposes a method for different VPNs to share the use of a single IPsec tunnel, which can greatly reduce the number of SAs required in a multi-VPN scenario. "A Reference Implementation of Ascertaining RPKI Signed Objects to be Validated in Incremental Updates", Di Ma, Yu Zhang, 2024-03-04, This document describes a reference implementation of how an RP ascertains which RPKI signed objects that need to be validated during a transaction of RPKI incremental update from the perspective of this RP. "A YANG Data Model for Network Element Threat Surface Management", Feifei Hu, Danke Hong, Liang Xia, 2024-03-04, This document defines a base YANG data model for network element threat surface management that is application- and technology- agnostic. "Hierarchical methods of computing metrics distribution", Xinxin Yi, Naihan Zhang, Hang Shi, 2024-03-04, This document analyzes the necessarity of setting hierarchical methods of computing metrics distribution. Besides, we propose the workflow of hierarchical metric distribution for different CATS frameworks. "Alternate Marking Deployment Status and Considerations", Tianran Zhou, Zhenbin Li, 2024-03-04, Operators have started the deployment of Alternate Marking in their networks for different scenarios. This document introduces several deployment cases of Alternate Marking in operator networks. Some considerations about the Alternate Marking deployments are also collected. "Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, 2024-03-04, A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. "A YANG Model for Application-aware Networking (APN)", Shuping Peng, Zhenbin Li, Ran Pang, Huiyue Zhang, 2024-03-04, Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute (incl. APN ID and/or APN Parameters) to enable fine grained service provisioning. This document defines a YANG module for APN. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "Dissemination of BGP Flow Specification Rules for APN", Shuping Peng, Zhenbin Li, Huiyue Zhang, Ran Pang, Yong Cui, 2024-03-04, A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute including APN ID and/or APN Parameters. The dynamic Flow Spec mechanism for APN is designed for the new applications of traffic filtering in an APN domain as well as the traffic control and actions at the policy enforcement points in this domain. These applications require coordination among the ASes within a service provider. This document specifies a new BGP Flow Spec Component Type in order to support APN traffic filtering. The match field is the APN ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsulation when matched to the corresponding Flow Spec rules. "Benchmarking Methodology for Segment Routing", Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene, 2024-03-04, 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. "SRv6 Service Benchmarking Guideline", Xuesong Geng, Zhu Keyi, Tianran Zhou, 2024-03-04, This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. "Application-aware IPv6 Networking (APN6) Encapsulation", Zhenbin Li, Shuping Peng, Chongfeng Xie, Shuai Zhang, 2024-03-04, Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the APN header and its encapsulation in the IPv6 data plane. "Post-Quantum Cryptography enhancement in EAP-AKA prime", Aritra Banerjee, Tirumaleswar Reddy.K, 2024-03-04, Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [I-D.ietf-emu-aka-pfs], 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 making it quantum-safe. "Application-aware Networking (APN) Implementation and Deployment Status", liuy619@chinaunicom.cn, Qingbang Xu, Jianwei Mao, 2024-03-04, This draft provides an overview of Application-aware Networking (APN) deployment status. It lists various APN features that have been deployed in the production networks. It also provides an overview of APN implementation status. "BGP Link State Extensions for Scalable Network Resource Partition", Jie Dong, Yongqing Zhu, Zehua Hu, Jun Ge, KaZhang, 2024-03-04, 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. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. "IPv6-Mostly Networks: Deployment and Operations Considerations", Jen Linkova, 2024-03-04, This document discusses an deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). "Discovery of Network-designated CoRE Resolvers", Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch, 2024-03-04, This document specifies solutions to discover DNS resolvers that support encrypted DNS resolution in constrained environments. The discovery is based DNS SVCB records, Router Advertisements, or DHCP. In particular, the proposed specification allows a host to learn DNS over CoAP (DoC) servers, including configurations to use DoC over TLS/DTLS, OSCORE, and EDHOC when resolving names. "Applicability of GMPLS for fine grain Optical Transport Network", Yi Lin, Liuyan Han, Yang Zhao, Raul Munoz, 2024-03-04, ITU-T Recommendation G.709/Y.1331 Edition 6.5 [G709-E6.5] introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. "EAP Multiple Pre-Shared Keys (EAP-MPSK) Method", Lei YAN, 2024-03-04, This document defines an Extensible Authentication Protocol (EAP) method for supporting the negotiation of a PSK among multiple PSKs. "BGP Link-State Extensions for Source Address Validation Networks (SAVNET)", tongtian124, Ran Pang, Nan Geng, Mingxing Liu, 2024-03-04, BGP Link-state uses the BGP protocol to collect and report network topology to the network controller. This document defines a new type of BGP-LS NLRI for reporting source address validation-related information to the controller. The reported information can be used to generate SAV rules centrally. "Operations, Administration and Maintenance (OAM) for Computing-Aware Traffic Steering", FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan, 2024-03-04, 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, 2024-03-04, 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, 2024-03-04, The document [I-D.draft-mhkk-dmm-srv6mup-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 optimal IPv6 dataplane routing information. However, when anycast address is used for service in data network (DN), this solution can be enhanced to dynamically set up the dataplane to the optimal service instance. This document discusses a solution to integrate computing-aware traffic steering capabilities to the mentioned MUP architecture. The target applied use-case is the anycast IP services scenario, where different instances that share the same anycast address of the service can serve the user request. 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 dataplane routing information to the optimal service instance. "Signaling Use Cases for Traffic Differentiation", Sridharan Rajagopalan, Dan Wing, Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-03-04, Host-to-network signaling can improve the user experience by informing the network which flows are more important and which packets within a flow are more important. The differentiated service may be provided at the network (e.g., packet prioritization), the sender (e.g., adaptive transmission), or through cooperation of both the sender and the network. This document outlines use-cases that highlight the need for a new signaling protocol from the receiver to its network elements which enables different traffic treatment. "SAVNET Use Cases", 1211176911910469110103, Xueyan Song, Changwang Lin, Nan Geng, 2024-03-04, 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. "Best practices for traffic steering to SRv6", Gary Geng, Yisong Liu, Chongfeng Xie, Changwang Lin, 2024-03-04, This document primarily describes the traffic steering towards SRv6- BE and SRv6-TE respectively, providing an overview of the main traffic steering methods for these two approaches. Furthermore, it discusses the recommended traffic steering methods for various typical scenarios. "Intra-domain SAV Support via BGP", Weiqiang Cheng, Changwang Lin, 1211176911910469110103, 2024-03-04, This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAVNET table entries based on intra-domain next hop SAVNET rules. The generation of intra- domain next hop SAVNET rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAVNET rules to generate the SAVNET rule table for source prefixes. "BGP Flowspec for Computing-Aware Traffic Steering", Changwang Lin, Huijuan Yao, 2024-03-04, A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework, This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. "Distribute Service Metric By BGP", Changwang Lin, Huijuan Yao, 2024-03-04, 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 server 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. "Host to Network Signaling Use Cases for Collaborative Traffic Differentiation", Sridharan Rajagopalan, Dan Wing, Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-03-17, Host-to-network (and vice versa) signaling can improve the user experience by informing the network which flows are more important and which packets within a flow are more important without having to disclose the content of the packets being delivered. The differentiated service may be provided at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission or session migration), or through cooperation of both the host and the network. This document lists use cases demonstrating the need for a mechanism to share metadata about flows between a receiving host and its networks to enable differentiated traffic treatment for packets sent to the host. Such a mechanism is typically implemented using a signaling protocol between the host and a set of network elements. "An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems", Jaehoon Jeong, Yiwen Shen, 2024-03-04, 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 like 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. "Scenarios and Potential Future Work of Enterprise Network Policies", Bing Liu, Qiangzhou Gao, liuy619@chinaunicom.cn, 2024-03-04, This document describes several typical scenarios of utilizing network policies against enterprise networks, and discusses some existing work and the limitations. Lastly, this document proposes several aspects of potential future work that might led to a formation of policy plane for enterprise networks. "Non-source-routed Multicast in SR Networks", Zhaohui Zhang, IJsbrand Wijnands, Hooman Bidgoli, Yisong Liu, 2024-03-04, 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. "Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP", Ruixue Wang, Changwang Lin, Mengxiao Chen, Fengwei Qin, Qi Zhang, wangwenxuan, 2024-03-04, 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. "Structured vacation notices", Hans-Joerg Happel, 2024-03-04, This document describes a machine-readable format for vacation notice messages. It is supposed to be used in conjuction with conventional, human-readable vacation notices. "CDNI Source Access Control Metadata", Pankaj Chaudhari, Glenn Goldstein, Will Power, Arnon Warshavsky, 2024-03-04, 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 Client Access Control Metadata", Pankaj Chaudhari, Glenn Goldstein, Will Power, Arnon Warshavsky, 2024-03-17, 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. "CDNI Delivery Metadata", Guillaume Bichot, Alfonso Siloniz, Glenn Goldstein, 2024-03-04, This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, Open Caching request delegation behavior for Open Caching node selection, and request routing modes of traffic delegation. "CDNI Private Features Metadata", Arnon Warshavsky, Glenn Goldstein, 2024-03-04, 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. "Compute-Aware Traffic Steering for Midhaul Networks", Luis Contreras, Mark Watts, 2024-03-04, Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. "Flow Metadata for Collaborative Host/Network Signaling", Sridharan Rajagopalan, Dan Wing, Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-03-04, This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. "IPv6 Hop-by-hop and Destination Options Forwarding In Routers", Kyle Ouellette, 2024-03-04, It has become accepted that packets containing IPv6 Extension Headers, especially Hop-by-hop Options, are frequently dropped on the Internet. However, the question still remains as to why they get dropped and what type of devices may be dropping them. This document describes research conducted to isolate routers in a simple topology, with minimal configuration, and shows that router implementations alone are likely not the cause of packets containing IPv6 Extension Headers being dropped on the Internet. "Remote attestation over EDHOC", Yuxuan Song, 2024-03-04, 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. "An Identitifier Proof-of-Possession Mechanism", Jon Peterson, 2024-03-04, This document specifies a means for a third-party service to prove and attest the association of a communications platform with a particular user's telephone number. This capability supports secure enrollment for users of messaging platforms or similar real-time communication applications, for cases where users assert telephone numbers as communication identifiers, and interoperating platforms need to verify that identifiers are being properly attested. This general approach can potentially work with other forms of Service Independent Identifiers (SIIs) in the More Instant Messaging Interoperability (MIMI) framework. "A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology", Oscar de Dios, Samier Barguil, Victor Lopez, Daniele Ceccarelli, Benoit Claise, 2024-03-04, This document defines a YANG data model for representing an abstracted view of a network topology that contains Intermediate System to Intermediate System (IS-IS). This document augments the 'ietf-network' data model by adding IS-IS concepts and explains how the data model can be used to represent the IS-IS topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "Consideration for IP-Based TVR (Time-Variant Routing)", Jing Wang, 2024-03-04, Satellite network are one of the TVR's use case. This document makes some considerations on using IP for the satellite network. "Light Clients for MLS", Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk, 2024-03-04, 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 cost, especially when joining a group. This document defines Light MLS, an extension that allows for "light clients". 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. "Workload Identity in a Multi System Environment (WIMSE) Architecture", Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig, 2024-03-04, 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. Workloads need to be provisioned with a unique identity when they are started. This information and their security context needs to be passed along the call chain. This architecture document discusses the motivation for designing and standardizing protocols and payloads for conveying identity and security context information. "Considerations for common QoS IPv6 extension header(s)", Toerless Eckert, Jinoo Joung, Shaofu Peng, Xuesong Geng, 2024-03-04, This document is written to start a discussion and collect opinions and ansers to questions raised in this document on the issue of defining IPv6 extension headers for DETNET-WG functionality with IPv6. "Messaging Layer Security Ciphersuite using XWing Key Exchange Mechanism", Rohan Mahy, 2024-03-04, This document registers a new Messaging Layer Security (MLS) ciphersuite using the X-Wing hybrid post-quantum resistant / traditional (PQ/T) Key Exchange Mechanism (KEM). "STI Certificate Transparency", Chris Wendt, Robert Sliwa, Alec Fenichel, Vinit Gaikwad, 2024-03-17, 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. "Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson, Magnus Westerlund, 2024-03-04, This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and is a hybrid loss- and delay based congestion control/rate management algorithm that also supports ECN and L4S. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) and 5G system simulator and is shown to achieve both low latency and high video throughput in these scenarios. This specification obsoletes RFC 8298. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. "Private Inexpensive Norm Enforcement (PINE) VDAF", Junye Chen, Christopher Patton, 2024-03-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. "Secure Objects for Media over QUIC", Cullen Jennings, Suhas Nandakumar, 2024-03-04, This document describes end-to-end encryption and authentication mechanism for application objects intended to be delivered over Media over QUIC Transport (MOQT). "Ranking Domain Name System data", Paul Hoffman, Shumon Huque, Willem Toorop, 2024-03-04, This document extends the list ranking the trustworthiness of domain name system (DNS) data (see Section 5.4.1 of [RFC2181]). The list is extended with entries for root server names and addresses built-in resolvers, and provided via a root hints file with the lowest trustworthiness, as wel as an entry for data which is verifiable DNSSEC secure with the highest trustworthiness. This document furthermore assigns ranked values to the positions of the list for easier reference and comparison of trustworthiness of DNS data. "EVPN Group Policy", Wen Lin, Dhananjaya Rao, Ali Sajassi, Michael Smith, Larry Kreeger, 2024-03-04, 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. "Unicode Separated Values (USV)", Joel Henderson, 2024-03-16, Unicode Separated Values (USV) is a data format that uses Unicode characters to mark parts. USV builds on ASCII separated values (ASV), and provides pragmatic ways to edit data in text editors by using visual symbols and layouts. "Window Sizing for Zstandard Content Encoding", Nidhi Jaju, W. Handte, 2024-03-04, Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, causing interoperability issues. This document updates the window size limit in RFC8878 from a recommendation to a requirement in HTTP contexts. "5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS", Luis Contreras, Ivan Bykov, Krzysztof Szarkowicz, 2024-03-04, 5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. "OpenPGP Replacement Key Signalling Mechanism", Daphne Shaw, Andrew Gallagher, 2024-03-04, This document specifies a method in OpenPGP to suggest a replacement for an expired or revoked key. "SRv6 SFC Architecture with SR-aware Functions", Wataru Mishima, 59 61, 2024-03-04, 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, Richard Barnes, Suhas Nandakumar, 2024-03-04, 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. "Including Additional Records for DNSSD in DNS Push Subscriptions", Ted Lemon, Di Ma, 2024-03-04, This document extends DNS Push Notifications by providing ways for DNS Push subscribers to track additional data as well as direct answers to DNS questions. This is analogous to the support for additional data specified for multicast DNS, for example. "MoWIE for Network Aware Application", Daniel Mertus, Yuhang Jia, Yunfei Zhang, Richard Yang, Gang Li, Yixue Lei, Yunbo Han, Sabine Randriamasy, 2024-03-04, With the deployment of 5G networks, cloud-based interactive services such as cloud gaming have gained substantial attention. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the quality perceived by a user of a mobile and wireless device may vary widely as a function of many factors, and unhandled changes can substantially compromise the user's QoE. In this document, we investigate network-aware applications (NAA), which realize cloud-based interactive services with improved QoE, by efficient utilization of a solution named Mobile and Wireless Information Exposure (MoWIE). In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamics of the underlying network and can be made available to applications through MoWIE; using such an information, the applications can then adapt key control knobs such as media codec schemes, encapsulation, and application layer processing to minimize QoE distortion. Following evaluations we give a cursory overview of the design space for implementing MoWIE "Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework", Oscar de Dios, Jean-Francois Bouquier, Julien Meuric, Gyan Mishra, Gabriele Galimberti, 2024-03-04, This document provides general overarching guidelines for control and management of packet over optical converged networks with coherent 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 coherent pluggables. The document provides a gap analysis to solve the use cases. "ML-KEM Post-Quantum Key Agreement for TLS 1.3", Deirdre Connolly, 2024-03-04, This memo defines ML-KEM as a standalone NamedGroup for use in TLS 1.3 to achieve post-quantum key agreement. "Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network", liuy619@chinaunicom.cn, Mengyao Han, 2024-03-04, This document describes the use cases and related requirements of Massive Data Transmission(MDT)in High Bandwidth-delay Product (BDP) Network. To achieve MDT, it is necessary to implement service identification and traffic record, network layer load balancing, transmission protocol optimization, etc. "Mangrove: A Unified Framework for Internet Topology, Routing Abstraction, and Modeling", Richard Yang, Bradley Lewis, Daniel Mertus, Alex Shi, Joseph Zhang, 2024-03-05, This document describes a novel system called Mangrove for obtaining global visibility across the Internet. It achieves this through constructing a comprehensive, unified representation of the Internet's topology and routing behavior by aggregating and indexing diverse data sources. he core challenge is obtaining an accurate, up-to-date model of how packets traverse the global Internet given the Internet's vast scale, dynamic nature, and fragmented visibility across multiple organizations collecting data in different formats. Mangrove addresses this by leveraging the hierarchical structure and natural abstractions of Internet architecture. It collects and integrates data from traceroute measurements, BGP routing tables, IP allocation records, and active broadband measurements. This multi-source data is partitioned and indexed across multiple granularity levels - geographic regions, autonomous systems, and IP prefixes - allowing effective storage, querying, and scalable processing. Mangrove constructs a unified topology and routing representation augmented with an extensible ruleset derived from Internet axioms and measured data. For arbitrary source-destination pairs, it computes estimated packet paths and associated performance metrics at the highest feasible granularity level based on available information completeness. The system handles real-time Internet dynamics through incremental rule refinement using detected changes in routing data and measurements. This enables timely updates to the topology model without full recomputation. Mangrove aims to provide researchers and operators an unprecedented unified Internet view for analysis, optimization, planning, security, and regulatory tasks. "Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez, 2024-03-13, 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. "Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members", Liyan Gong, Changwang Lin, Mengxiao Chen, Ketan Talaulikar, Les Ginsberg, Peter Psenak, 2024-03-16, 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. "PQ/T Hybrid KEM: HPKE with JOSE/COSE", Tirumaleswar Reddy.K, Hannes Tschofenig, 2024-03-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, 2024-03-16, 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 Relay Party's output. "Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations", Kotikalapudi Sriram, Job Snijders, Doug Montgomery, 2024-03-17, 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. "JSON Fine Grained Access", Jinling Zhang, cheng Jiang, lingling Ji, 2024-03-17, This document defines a JSON-based fine-grained access (JSON-FA) method, which aims to provide a flexible and easy-to-implement way to achieve fine-grained access control in JSON data. "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, Weiqiang Cheng, 2024-03-17, 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 . "SRv6 Deployment Consideration", Hui Tian, Chongfeng Xie, Edmore Chingwena, Shuping Peng, Qiangzhou Gao, 2024-03-18, SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced. "JOSE: Deprecate 'none' and 'RSA1_5'", Neil Madden, 2024-03-18, This draft updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". "BBS per Verifier Linkability", Vasilis Kalos, Greg Bernstein, 2024-03-18, The BBS Signatures scheme describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, build 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 where that require from the Verifier, to be able to track the BBS proofs they receive from the same entity. 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 different parties. This provides a way for a recipient to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. "Methods for Remotely Measuring IP Spoofing Capability", Shuai Wang, Dan Li, Ruifeng Li, Qian Cao, 2024-03-18, This document summarizes and standardizes methods for remotely measuring a network's IP spoofing capability. For outbound spoofing capability measurement, i.e., whether the network allows IP spoofing traffic to be sent from inside the network to the outside of the network, DNS traceroute can be used to check whether spoofed packets are generated in the network and sent to outside of the network. For inbound spoofing capability measurment, i.e., whether the network allows IP spoofing traffic from the outside the network to arrive inside, DNS resolver and ICMPv6 rate limiting mechanism can be utilized to check whether spoofed packets are received by devices in the network. "DNS Extensions for Proxying IP in HTTP", David Schinazi, 2024-03-18, 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 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. "Add CB_LAYOUTRECLL_DEVICE to NFSv4.2", Thomas Haynes, 2024-03-18, The Parallel Network File System (pNFS) allows for the metadata server to use CB_LAYOUTRECALL to recall a layout from a client by file id or file system id or all. It also allows the server to use CB_NOTIFY_DEVICEID to delete a devicid. It does not provide a mechanism for the metadata server to recall all layouts that have a data file on a specific deviceid. This document presents an extension to RFC8881 to allow the server recall layouts from clients based on deviceid. Network Time Protocols (ntp) ---------------------------- "NTP Interleaved Modes", Miroslav Lichvar, Aanchal Malhotra, 2021-10-18, This document extends the specification of Network Time Protocol (NTP) version 4 in RFC 5905 with special modes called the NTP interleaved modes, that enable NTP servers to provide their clients and peers with more accurate transmit timestamps that are available only after transmitting NTP packets. More specifically, this document describes three modes: interleaved client/server, interleaved symmetric, and interleaved broadcast. "Roughtime", Watson Ladd, Marcus Dansarie, 2024-03-04, This document specifies Roughtime - a protocol that aims to achieve rough time synchronization even for clients without any idea of what time it is. 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-ntp-roughtime/. Source for this draft and an issue tracker can be found at https://github.com/wbl/roughtime-draft. "Updating the NTP Registries", Rich Salz, 2023-12-14, The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries, and makes updates where necessary. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. "NTPv5 Use Cases and Requirements", James Gruessing, 2024-01-25, This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supersede version 4 of the NTP protocol presently referred to as NTP version 5 ("NTPv5"). It aims to define what capabilities and requirements such a protocol possesses, informing the design of the protocol in addition to capturing any working group consensus made in development. "Network Time Protocol Version 5", Miroslav Lichvar, 2023-10-19, This document describes the version 5 of the Network Time Protocol (NTP). "NTP Over PTP", Miroslav Lichvar, 2024-01-18, This document specifies a transport for the Network Time Protocol (NTP) client-server and symmetric modes using the Precision Time Protocol (PTP) to enable hardware timestamping on network interface controllers which can timestamp only PTP messages and enable corrections in PTP transparent clocks. Network Virtualization Overlays (nvo3) -------------------------------------- "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Fabio Maino, Larry Kreeger, Uri Elzur, 2023-11-04, This document describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with four new capabilities: support for multi-protocol encapsulation, support for operations, administration and maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e. Broadcast, Unknown unicast, or Multicast), and explicit versioning. New protocol capabilities can be introduced via shim headers. "Network Virtualization Overlays (NVO3) Encapsulation Considerations", Sami Boutros, Donald Eastlake, 2024-02-19, The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at starting from the output of an NVO3 encapsulation design team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats. There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. Based on these considerations, the Working Group determined that Geneve with a few modifications as the common encapsulation. This document provides more details, particularly in Section 7. "OAM for use in GENEVE", Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti, 2023-12-06, This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. Web Authorization Protocol (oauth) ---------------------------------- "OAuth 2.0 Security Best Current Practice", Torsten Lodderstedt, John Bradley, Andrey Labunets, Daniel Fett, 2024-02-08, This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in [RFC6749], [RFC6750], and [RFC6819] to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. It further deprecates some modes of operation that are deemed less secure or even insecure. "JWT Response for OAuth Token Introspection", Torsten Lodderstedt, Vladimir Dzhuvinov, 2021-09-04, This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. "OAuth 2.0 for Browser-Based Apps", Aaron Parecki, David Waite, Philippe De Ryck, 2024-02-28, 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, 2024-01-09, 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, 2024-03-04, This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. "Cross-Device Flows: Security Best Current Practice", Pieter Kasselman, Daniel Fett, Filip Skokan, 2024-03-01, 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, 2024-03-04, 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, 2023-10-23, This specification defines a new method of client authentication for OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme. "OAuth 2.0 Protected Resource Metadata", Michael Jones, Phil Hunt, Aaron Parecki, 2024-02-01, This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. "Token Status List", Tobias Looker, Paul Bastian, Christian Bormann, 2024-03-03, This specification defines status list 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 JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs) and ISO mdoc. The status list token data structures themselves are also represented as JWTs or CWTs. "Transaction Tokens", Atul Tulshibagwale, George Fletcher, Pieter Kasselman, 2024-03-16, 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 optionally immutably assert to downstream workloads that they were invoked in the call chain of the request. "OAuth Identity and Authorization Chaining Across Domains", Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell, 2024-02-19, This specification defines a mechanism to preserve identity information and federate authorization 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. Oblivious HTTP Application Intermediation (ohai) ------------------------------------------------ "Chunked Oblivious HTTP Messages", Tommy Pauly, Martin Thomson, 2024-01-21, 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. "Chunked Oblivious HTTP Messages", Tommy Pauly, Martin Thomson, 2024-02-09, 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) ---------------------------------------------------- "OpenPGP", Paul Wouters, Daniel Huigens, Justus Winter, Niibe Yutaka, 2024-01-04, This document specifies the message formats used in OpenPGP. OpenPGP 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 OpenPGP 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 obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). "Post-Quantum Cryptography in OpenPGP", Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler, 2024-03-04, 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. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices", Tirumaleswar Reddy.K, Dan Wing, Blake Anderson, 2024-03-17, This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. "Authorized update to MUD URLs", Michael Richardson, Wei Pan, Eliot Lear, 2024-03-01, 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 "Operational Considerations for use of DNS in IoT devices", Michael Richardson, Wei Pan, 2024-02-08, This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document makes recommendations on when and how to use DNS names in MUD files. "Ownership and licensing statements in YANG", Eliot Lear, Carsten Bormann, 2023-10-23, This memo provides for an extension to RFC 8520 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. "TACACS+ TLS 1.3", Thorsten Dahm, dcmgash@cisco.com, Andrej Ota, John Heasley, 2024-01-23, The TACACS+ Protocol [RFC8907] provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document, a companion to the TACACS+ protocol [RFC8907], adds Transport Layer Security (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former inferior security mechanisms. "Export of On-Path Delay in IPFIX", Thomas Graf, Benoit Claise, Alex Feng, 2024-01-14, This document introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay on the IOAM transit and decapsulation nodes. "Link-Layer Types for PCAP and PCAPNG Capture File Formats", Guy Harris, Michael Richardson, 2024-01-30, This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. "A Data Manifest for Contextualized Telemetry Data", Benoit Claise, Jean Quilbeuf, Diego Lopez, Ignacio Martinez-Casanueva, Thomas Graf, 2024-03-04, Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents 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 Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level 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 system in order to keep the collected data fully exploitable by the data scientists. "Export of UDP Options Information in IP Flow Information Export (IPFIX)", Mohamed Boucadair, Tirumaleswar Reddy.K, 2024-01-23, 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. "Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements", Mohamed Boucadair, Benoit Claise, 2024-02-06, This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. "Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry", Mohamed Boucadair, Benoit Claise, 2024-02-06, This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. "Finding and Using Geofeed Data", Randy Bush, Massimo Candela, Warren Kumari, Russ Housley, 2024-02-22, This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed data files. This document obsoletes RFC 9092. "A YANG Data Model and RADIUS Extension for Policy-based Network Access Control", Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King, 2024-02-02, 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 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, 2024-02-09, The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. 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, 2024-03-16, This document specifies a YANG service data model for Attachment Circuits (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 service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. "A Network YANG Data Model for Attachment Circuits", Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu, 2024-02-09, 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., Network Slice Service). A companion service model is specified in I-D.ietf-opsawg-teas- attachment-circuit. The module augments the Service Attachment Point (SAP) model 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, 2024-02-09, The document specifies a module that updates existing service and network Virtual Private Network (VPN) modules with the required information to bind specific services to ACs that are created using the Attachment Circuit (AC) service and network models. "An Information Model for Packet Discard Reporting", John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, 2024-02-05, The primary function of a network is to transport packets and deliver them according to a service level objective. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Router-reported packet loss is the most direct signal for network operations to identify customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss. Pseudowire And LDP-enabled Services (pals) ------------------------------------------ "Private Line Emulation over Packet Switched Networks", Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Chris Brown, 2023-10-21, This document describes a method for encapsulating high-speed bit- streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency. Path Computation Element (pce) ------------------------------ "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Dhruv Dhody, Vishnu Beeram, Jonathan Hardwick, Jeff Tantsura, 2024-03-18, This document defines 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. The data model includes configuration and state data. "Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks", Aijun Wang, Boris Khasanov, Sheng Fang, Ren Tan, Chun Zhu, 2024-02-01, This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End-to-End (E2E) traffic assurance in the Native IP network under PCE as a central controller (PCECC). "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane", Cheng Li, Prejeeth Kaladharan, Siva Sivabalan, Mike Koldychev, Yongqing Zhu, 2024-02-15, Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head- end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). 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 SR can be applied to both MPLS and IPv6 forwarding planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 forwarding planes. The PCEP extension and mechanisms to support SR- MPLS have been defined. This document describes the extensions required for SR support for the IPv6 data plane in the Path Computation Element communication Protocol (PCEP). "Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.", Siva Sivabalan, Clarence Filsfils, Jeff Tantsura, Stefano Previdi, Cheng Li, 2023-03-27, In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (SID) (called BSID) as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering Label Switched Path or an SR Traffic Engineering path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or Segment Identifier. It further specifies an extension to Path Computation Element (PCE) communication Protocol(PCEP) for reporting the binding value by a Path Computation Client (PCC) to the PCE to support PCE-based Traffic Engineering policies. "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2024-02-26, 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, 2024-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, Colby Barth, Shuping Peng, Hooman Bidgoli, 2024-03-17, Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies Path Computation Element Communication Protocol (PCEP) extension to associate candidate paths of the SR Policy. Additionally, this document updates [RFC8231] to allow stateful bringup of an SR LSP, without using PCReq/PCRep messages. This document is applicable to both Segment Routing over MPLS and to 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, 2024-01-01, 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, 2023-10-23, 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 MPLS toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. "PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra, 2024-01-16, 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 a mechanism to encode multiple paths for a single set of objectives and constraints. This is a generic PCEP mechanism, not specific to any path setup type or dataplane. The mechanism is applicable to both stateless and stateful PCEP. "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng, 2024-03-17, 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) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an 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 a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. "Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects", Cheng Li, Haomian Zheng, Stephane Litkowski, 2024-03-17, This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. "PCEP extensions for p2mp sr policy", Hooman Bidgoli, Dan Voyer, Saranya Rajarathinam, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan, 2024-03-03, SR P2MP policies are 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 Leaves. "PCEP Extension for Layer 2 (L2) Flow Specification", Dhruv Dhody, Adrian Farrel, Zhenbin Li, 2023-12-25, 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. 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 information in PCE-based Networks.", Samuel Sidor, Alex Tokar, Shaofu Peng, Shuping Peng, Andrew Stone, 2024-02-01, The SR-Algorithm associated with a Prefix Segment-ID (SID) defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the SR- Algorithm associated with each Prefix SID used in PCE-computed paths, as well as signalling a specific SR-Algorithm as a constraint to the PCE. "Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP)", Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, 2024-01-28, 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 SR path is not available at the headend. This document specify the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR and other scenarios. 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, 2024-01-08, 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, 2024-03-18, 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). "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, 2024-02-04, 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. "Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE.", Cheng Li, Haomian Zheng, Siva Sivabalan, Samuel Sidor, Zafar Ali, 2024-02-05, A Stateful Path Computation Element (PCE) maintains information on the current network state, including computed Label Switched Path (LSPs), reserved resources within the network, and the pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for the associated and the dependent LSPs, received from a Path Computation Client (PCC). RFC 7470 defines a facility to carry vendor-specific information in stateless Path Computation Element Communication Protocol (PCEP). This document extends this capability for the Stateful PCEP messages. "PCEP Extensions for BIER-TE", Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang, 2023-11-04, Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. 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 as described in [RFC9262]. 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 BIER-TE. "PCEP extensions for Circuit Style Policies", Samuel Sidor, Praveen Maheshwari, Andrew Stone, Luay Jalil, Shuping Peng, 2024-02-26, This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. "Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions", Quan Xiong, Shaofu Peng, Fengwei Qin, Junfeng Zhao, 2024-02-25, 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. Privacy Enhancements and Assessments Research Group (pearg) ----------------------------------------------------------- "Guidelines for Performing Safe Measurement on the Internet", Iain Learmonth, Gurshabad Grover, Mallory Knodel, 2024-01-12, 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, 2023-10-11, This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE. "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Brian Haberman, 2023-11-09, This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. "Internet Group Management Protocol, Version 3", Brian Haberman, 2023-11-09, This document specifies a revised Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 3376. "PIM Join/ Prune Attributes for LISP Environments using Underlay Multicast", Vengada Govindan, Stig Venaas, 2024-02-26, This document specifies an update to the PIM Receiver RLOC Join/ Prune attribute that supports the construction of multicast distribution trees where the root 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). "P2MP Policy Ping", Hooman Bidgoli, Dan Voyer, Rishabh Parekh, Zhaohui Zhang, 2023-10-21, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. 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, 2023-10-06, 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. "PIM Light", Hooman Bidgoli, Stig Venaas, Mankamana Mishra, Zhaohui Zhang, Mike McBride, 2024-02-26, This document specifies a new Protocol Independent Multicast interface which does not need PIM Hello to accept PIM Join/Prunes. "IANA Considerations for Internet Group Management Protocols", Brian Haberman, 2023-10-23, This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and updates RFC 4443. "Multicast Lessons Learned from Decades of Deployment Experience", Dino Farinacci, Lenny Giuliano, Mike McBride, Nils Warnke, 2024-03-04, 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. "Updates to Dynamic IPv6 Multicast Address Group IDs", Nathan Karstens, Dino Farinacci, Mike McBride, 2023-11-06, 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, 2023-10-06, 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 "Any Source" IP Multicasting (ASM)", Steve Deering, Toerless Eckert, 2023-10-18, This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support Any Source Multicast (ASM) IP Multicasting or abbreviated IP Multicast. Distribution of this memo is unlimited. This document replaces [RFC1112] for anything but its specification of the IGMP version 1 protocol. "Zero-Configuration Assignment of IPv6 Multicast Addresses", Nathan Karstens, Dino Farinacci, Mike McBride, 2023-11-05, Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a reserved range and prevent collisions by using 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, 2024-03-04, 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. Privacy Preserving Measurement (ppm) ------------------------------------ "Distributed Aggregation Protocol for Privacy Preserving Measurement", Tim Geoghegan, Christopher Patton, Brandon Pitman, Eric Rescorla, Christopher Wood, 2024-02-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, 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 (PPM) which can be used to collect aggregate data without revealing any individual user's data. Post-Quantum Use In Protocols (pquip) ------------------------------------- "Terminology for Post-Quantum Traditional Hybrid Schemes", Florence D, 2024-02-02, One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. "Post-Quantum Cryptography for Engineers", Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, 2024-02-22, The presence of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, since the assumptions about the intractability of the mathematical problems for these algorithms that offer confident levels of security today no longer apply in the presence of a CRQC. This means there is a requirement to update protocols and infrastructure to use post-quantum algorithms, which are public-key algorithms designed to be secure against CRQCs as well as classical computers. These new public-key algorithms behave similarly to previous public key algorithms, however the intractable mathematical problems have been carefully chosen so they are hard for CRQCs as well as classical computers. This document explains why engineers need to be aware of and understand post-quantum cryptography. It emphasizes the potential impact of CRQCs on current cryptographic systems and the need to transition to post-quantum algorithms to ensure long-term security. The most important thing to understand is that this transition is not like previous transitions from DES to AES or from SHA-1 to SHA-2. While drop-in replacement may be possible in some cases, others will require protocol re-design to accommodate significant differences in behavior between the new post-quantum algorithms and the classical algorithms that they are replacing. Privacy Pass (privacypass) -------------------------- "Privacy Pass Issuance Protocol", Sofia Celi, Alex Davidson, Steven Valdez, Christopher Wood, 2023-10-03, This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. "The Privacy Pass Architecture", Alex Davidson, Jana Iyengar, Christopher Wood, 2023-09-25, This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model that helps ensure the desired security and privacy goals are fulfilled. "The Privacy Pass HTTP Authentication Scheme", Tommy Pauly, Steven Valdez, Christopher Wood, 2023-10-23, This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme in this document can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present Privacy Pass tokens. "Rate-Limited Token Issuance Protocol", Scott Hendrickson, Jana Iyengar, Tommy Pauly, Steven Valdez, Christopher Wood, 2024-03-04, This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. "Public Metadata Issuance", Scott Hendrickson, Christopher Wood, 2023-11-25, This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. "The PrivateToken HTTP Authentication Scheme Extensions Parameter", Scott Hendrickson, Christopher Wood, 2023-11-25, This document specifies a new parameter for the "PrivateToken" HTTP authentication scheme. This purpose of this parameter is to carry extensions for Privacy Pass protocols that support public metadata. "Checking Resource Consistency with HTTP Mirrors", Benjamin Beurdouche, Matthew Finkel, Steven Valdez, Christopher Wood, Tommy Pauly, 2023-10-23, This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. "Checking Resource Consistency with HTTP Mirrors", Benjamin Beurdouche, Matthew Finkel, Steven Valdez, Christopher Wood, Tommy Pauly, 2024-01-30, This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. Quantum Internet Research Group (qirg) -------------------------------------- "Application Scenarios for the Quantum Internet", Chonggang Wang, Akbar Rahman, Ruidong Li, Melchior Aelmans, Kaushik Chakraborty, 2023-10-16, The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the Quantum Internet and categorizes them. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to describe a framework for applications, and describe a few selected application scenarios for the Quantum Internet.This document is a product of the Quantum Internet Research Group (QIRG). QUIC (quic) ----------- "QUIC-LB: Generating Routable QUIC Connection IDs", Martin Duke, Nick Banks, Christian Huitema, 2024-02-05, 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. "Main logging schema for qlog", Robin Marx, Luca Niccolini, Marten Seemann, Lucas Pardue, 2024-03-04, This document defines qlog, an extensible high-level schema for a standardized logging format. It allows easy sharing of data, benefitting common debug and analysis methods and tooling. The high- level schema is independent of protocol; separate documents extend qlog for protocol-specific data. The schema is also independent of serialization format, allowing logs to be represented in many 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, 2024-03-04, This document describes concrete qlog event definitions and their metadata for QUIC events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. 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, 2024-03-04, This document describes concrete qlog event definitions and their metadata for HTTP/3-related events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. 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, 2024-03-04, This document specifies an extension to QUIC that permits an endpoint to request that its peer changes 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, 2023-10-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/mirjak/draft-lmbdhk-quic-multipath. "QUIC Stream Resets with Partial Delivery", Marten Seemann, Kazuho Oku, 2024-02-28, 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. RADIUS EXTensions (radext) -------------------------- "RADIUS ALPN and removing MD5", Alan DeKok, 2024-02-26, This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an additional application protocol for RADIUS over (D)TLS. No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are removed. When this extension is used, the previous Authenticator field is repurposed to contain an explicit request / response identifier, called a Token. The Token also allows more than 256 packets to be outstanding on one connection. This extension can be seen as a transport profile for RADIUS, as it is not an entirely new protocol. It uses the existing RADIUS packet layout and attribute format without change. As such, it can carry all present and future RADIUS attributes. Implementation of this extension requires only minor changes to the protocol encoder and decoder functionality. The protocol defined by this extension is named "RADIUS version 1.1", or "RADIUS/1.1". "RADIUS and TLS-PSK", Alan DeKok, 2024-02-29, This document gives 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 insecure RADIUS/UDP to the use of the much more secure RADIUS/TLS. "(Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS", Jan-Frederik Rieckers, Stefan Winter, 2023-10-15, 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, 2023-11-07, 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. This document formally deprecates using the User Datagram Protocol (UDP) and of the Transmission Control Protocol (TCP) as transport protocols for RADIUS. These transports are permitted inside of secure networks, but their use in those networks is still discouraged. For all other environments, the use of secure transports such as IPsec or TLS is mandated. We also discuss additional security issues with RADIUS deployments, and give recommendations for practices which increase security and privacy. "Reverse CoA in RADIUS", Alan DeKok, Vadim Cargatser, 2023-11-07, 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, 2024-03-04, 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) ------------------------------------ "The Entity Attestation Token (EAT)", Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace, 2024-01-15, An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", Henk Birkholz, Michael Eckel, Shwetha Bhandari, Eric Voit, Bill Sulzen, Liang Xia, Tom Laffey, Guy Fedorkow, 2024-02-27, This document defines YANG Remote Procedure Calls (RPCs) and a few configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), or equivalent hardware implementations that include the protected capabilities as provided by TPMs as well as a corresponding software stack, included in the device components of the composite device the YANG server is running on. "TPM-based Network Device Remote Integrity Verification", Guy Fedorkow, Eric Voit, Jessica Fitzgerald-McKay, 2022-03-22, This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG)), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. "Reference Interaction Models for Remote Attestation Procedures", Henk Birkholz, Michael Eckel, Wei Pan, Eric Voit, 2024-03-04, This document describes interaction models for remote attestation procedures (RATS). 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. "A CBOR Tag for Unprotected CWT Claims Sets", Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann, 2024-03-04, When transported over secure channels, CBOR Web Token (CWT, RFC 8392) Claims Sets may not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. "Direct Anonymous Attestation for the Remote Attestation Procedures Architecture", Henk Birkholz, Christopher Newton, Liqun Chen, Dave Thaler, 2024-03-04, 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, 2024-03-04, 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. "EAT Media Types", Laurence Lundblade, Henk Birkholz, Thomas Fossati, 2023-11-07, Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). "Concise Reference Integrity Manifest", Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan, 2024-03-04, Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. "Concise TA Stores (CoTS)", Carl Wallace, Russ Housley, Thomas Fossati, Yogesh Deshpande, 2023-12-05, Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. "RATS Endorsements", Dave Thaler, Henk Birkholz, Thomas Fossati, 2023-12-01, 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 needed by a Relying Parties. This document explains the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements. "RATS Conceptual Messages Wrapper (CMW)", Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, 2024-02-27, This document defines the RATS conceptual message wrapper (CMW) format, a type of encapsulation format that can be used for any RATS messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. Additionally, the document describes a collection type that enables the aggregation of one or more CMWs into a single message. This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. Registration Protocols Extensions (regext) ------------------------------------------ "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect", Scott Hollenbeck, 2023-11-05, The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. "Registration Data Access Protocol (RDAP) Reverse Search", Mario Loffredo, Maurizio Martinelli, 2023-11-13, The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses", Mario Loffredo, Gavin Brown, 2023-12-07, This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. "Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)", Dmitry Belyavsky, James Gould, 2023-11-06, This document describes an EPP command-response extension that permits usage of Internationalized Email Addresses in the EPP protocol and specifies the terms when it can be used by EPP clients and servers. The Extensible Provisioning Protocol (EPP), being developed before the standards for SMTPUTF8 compliant addresses, does not support such email addresses. TO BE REMOVED on turning to RFC: The document is edited in the dedicated github repo (https://github.com/beldmit/eppeai). Please send your submissions via GitHub. "Redacted Fields in the Registration Data Access Protocol (RDAP) Response", James Gould, David Smith, Jody Kolker, Roger Carney, 2023-11-27, This document describes an RDAP extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. "Versioning in the Registration Data Access Protocol (RDAP)", James Gould, Dan Keathley, Mario Loffredo, 2023-12-08, This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. "RDAP RIR Search", Tom Harrison, Jasdip Singh, 2024-01-30, 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 IP and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. "Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values", Gavin Brown, 2024-03-01, This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. 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/epp-ttl-extension. "An RDAP Extension for Geofeed Data", Jasdip Singh, Tom Harrison, 2024-03-04, This document defines a new RDAP extension "geofeed1" for including a geofeed file URL in an IP Network object. "Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, William Carroll, Gautam Akiwate, 2024-02-28, 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 includes guidance concerning those 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 practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency. "Versioning in the Registration Data Access Protocol (RDAP)", James Gould, Dan Keathley, Mario Loffredo, 2024-02-27, This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. "An RDAP With Extensions Media Type", Andy Newton, Jasdip Singh, 2024-02-27, This document defines a media type for RDAP that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this media type with RDAP. "RDAP Extensions", Andy Newton, Jasdip Singh, Tom Harrison, 2024-02-27, This document describes and clarifies the usage of extensions in RDAP. Routing In Fat Trees (rift) --------------------------- "RIFT: Routing in Fat Trees", Tony Przygienda, Jordan Head, Pascal Thubert, Bruno Rijsman, Dmitry Afanasiev, 2024-02-19, This document defines a specialized, dynamic routing protocol for Clos and fat tree network topologies optimized towards minimization of control plane state as well as minimization of configuration and operational complexity. "YANG Data Model for Routing in Fat Trees (RIFT)", Zheng Zhang, Yuehua Wei, Shaowen Ma, Xufeng Liu, Bruno Rijsman, 2023-10-16, This document defines a YANG data model for the configuration and management of Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC8342. "RIFT Applicability", Yuehua Wei, Zheng Zhang, Dmitry Afanasiev, Pascal Thubert, Tony Przygienda, 2023-12-25, This document discusses the properties, applicability and operational considerations of RIFT in different network scenarios. It intends to provide a rough guide how RIFT can be deployed to simplify routing operations in Clos topologies and their variations. "RIFT Auto-EVPN", Jordan Head, Tony Przygienda, Wen Lin, 2024-02-29, This document specifies procedures that allow an EVPN overlay to be fully and automatically provisioned when using RIFT as underlay by leveraging RIFT's no-touch ZTP architecture. "RIFT Key/Value TIE Structure and Processing", Jordan Head, Tony Przygienda, 2024-03-04, 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, 2023-11-30, This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include itself, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. "Supporting Asymmetric Links in Low Power Networks: AODV-RPL", Charles Perkins, S.V.R Anand, Satish Anamalamudi, Bing Liu, 2023-08-17, 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. "Common Ancestor Objective Function and Parent Set DAG Metric Container Extension", Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thubert, 2023-11-08, High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. "Controlling Secure Network Enrollment in RPL networks", Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki, 2023-11-08, [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, 2023-09-18, By and large, a correct operation of a RPL network requires border routers to be up. In many applications, it is beneficial for the nodes to detect a crash of a border router as soon as possible to trigger fallback actions. This document describes RNFD, an extension to RPL that expedites border router failure detection, even by an order of magnitude, 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. RFC Series Working Group (rswg) ------------------------------- "The "xml2rfc" version 3 Vocabulary as Implemented", John Levine, Paul Hoffman, 2024-03-03, This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home pags at . Source code and issues list for this draft can be found at . "Updated RFC Format Framework", Paul Hoffman, Heather Flanagan, 2024-03-11, In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document is the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes how RFCs are published. This document obsoletes RFC 7990 and makes many significant changes to that document. It also updates the stability policy in RFC 9280. 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/draft- rswg-rfc7990-updates (https://github.com/paulehoffman/draft-rswg- rfc7990-updates). Issues can be raised there, but probably should be on the mailing list instead. "The Use of Non-ASCII Characters in RFCs", Paul Hoffman, Heather Flanagan, 2024-02-14, The RFC Series has evolved to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of RFCs is now in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes requirements and guidelines for the RFC Editor regarding the use of non-ASCII characters in RFCs. This document obsoletes RFC 7997. The differences reflect changes in the practices of the RFC series since RFC 7997 was published, and makes further changes based on agreements in the IETF community about what characters are allowed in RFCs. [[ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ]] Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ "JavaScript Session Establishment Protocol (JSEP)", Justin Uberti, Cullen Jennings, Eric Rescorla, 2023-09-21, This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. This specification obsoletes RFC 8829. Routing Area Working Group (rtgwg) ---------------------------------- "BGP Prefix Independent Convergence", Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra, 2023-10-01, 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. "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno, 2023-10-23, 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, 2024-01-16, This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR 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. 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, 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, 2024-03-17, This document describes a set of network-related problems enterprises face at the time of writing this document (2023) 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. "YANG Models for Quality of Service (QoS)", Aseem Choudhary, Mahesh Jethanandani, Ebben Aries, Helen Chen, 2024-01-31, This document describes a YANG model for configuration and operational data of Quality of Service (QoS) in network devices. "SRv6 Path Egress Protection", Zhibo Hu, Huaimo Chen, Mehmet Toy, Chang Cao, Tao He, 2024-02-01, 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, 2024-03-01, This document discusses the applicability of Bidirectional Forwarding Detection (BFD) for multipoint networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second convergence of the Active router and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798bis [Ed.Note: When the RFC 5798bis is published, change to the assigned new number]. "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", Acee Lindem, Aditya Dogra, 2024-01-04, This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798 which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768 which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. Secure Asset Transfer Protocol (satp) ------------------------------------- "Secure Asset Transfer (SAT) Interoperability Architecture", Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna, 2024-01-04, 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 (SAT) Use Cases", Venkatraman Ramakrishna, Thomas Hardjono, 2024-01-24, This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. Source Address Validation in Intra-domain and Inter-domain Networks (savnet) ---------------------------------------------------------------------------- "Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements", Dan Li, Jianping Wu, Lancheng Qin, Mingqing(Michael) Huang, Nan Geng, 2024-02-13, This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", Jianping Wu, Dan Li, Libin Liu, Mingqing(Michael) Huang, Kotikalapudi Sriram, 2024-02-18, This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. Static Context Header Compression (schc) ---------------------------------------- "Static Context Header Compression (SCHC) Architecture", Alexander Pelov, Pascal Thubert, Ana Minaburo, 2023-10-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, 2024-03-04, 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. "SCHC Access Control", Ana Minaburo, Laurent Toutain, Ivan Martinez, 2023-12-13, The framework for SCHC defines an abstract view of the rules, formalized through a YANG Data Model. In its original description, rules are static and shared by two endpoints. This document defines defines augmentation to the existing Data Model in order to restrict the changes in the rule and, therefore, the impact of possible attacks. System for Cross-domain Identity Management (scim) -------------------------------------------------- "SCIM Profile for Security Event Tokens", Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber, 2024-03-16, 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", Danny Zollner, Anjali Sehgal, 2024-03-01, 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, 2024-03-04, 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 Wifi EasyConnect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. 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, 2024-03-04, Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on any Transparency Service, with the guarantee that all Auditors and Verifiers will be able to verify them. "Detailed Software Supply Chain Uses Cases for SCITT", Henk Birkholz, Yogesh Deshpande, Dick Brooks, Bob Martin, Brian Knight, 2023-10-16, This document includes a collection of representative Software Supply Chain Use Case Descriptions. These use cases aim to identify software supply chain problems that the industry faces today and acts as a guideline for developing a comprehensive solution for these classes of scenarios. "SCITT Reference APIs", Henk Birkholz, Orie Steele, Jon Geater, 2024-03-04, This document describes a REST API that supports the normative requirements of the SCITT Architecture [I-D.draft-ietf-scitt-architecture]. Optional key discovery and query interfaces are provided to support interoperability issues with Decentralized Identifiers, X509 Certificates and Artifact Reposistories. Serialising Extended Data About Times and Events (sedate) --------------------------------------------------------- "Date and Time on the Internet: Timestamps with additional information", Ujjwal Sharma, Carsten Bormann, 2023-10-23, This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone. It updates RFC3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see Section 2. // (This "cref" paragraph will be removed by the RFC editor:) The // present version (-11) addresses comments received during IESG // review. Secure Media Frames (sframe) ---------------------------- "Secure Frame (SFrame)", Emad Omara, Justin Uberti, Sergio Murillo, Richard Barnes, Youenn Fablet, 2024-02-29, This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (selective forwarding units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. SIDR Operations (sidrops) ------------------------- "RPKI Signed Object for Trust Anchor Key", Carlos Martinez, George Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein, 2023-09-05, A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support planned key rolls without impacting RPKI validation. "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Job Snijders, Kotikalapudi Sriram, 2024-02-29, 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 type of AS_PATH verification provides detection and mitigation of route leaks and improbable AS paths. It also provides protection, to some degree, against prefix hijacks with forged-origin or forged-path-segment. "A Profile for Autonomous System Provider Authorization", Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison, 2023-11-07, 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, 2024-03-04, In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document is compatible with both. "A Profile for Route Origin Authorizations (ROAs)", Job Snijders, Ben Maddison, Matt Lepinski, Derrick Kong, Stephen Kent, 2023-12-14, This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)", Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery, 2024-03-04, 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. "On the use of the CMS signing-time attribute in RPKI Signed Objects", Job Snijders, Tom Harrison, 2024-02-10, In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types by way of a standard template (RFC 6488). That template includes an optional CMS signing-time attribute, representing the purported time at which the object was signed by its issuer. At the time when the standard template was defined, rsync was the only distribution mechanism for RPKI repositories. Since the publication of the standard template, a new, additional protocol for distribution of RPKI repositories has been developed: the RPKI Repository Delta Protocol (RRDP). While RPKI repository operators must provide rsync service, RRDP is typically deployed alongside it as well, and preferred by default by most Relying Party (RP) implementations. However, RP implementations also support fallback to rsync in the event of problems with the RRDP service. As deployment experience with RRDP has increased, the usefulness of optimizing switchovers by RPs from one mechanism to the other has become apparent. This document describes how Publishers and RPs can use the CMS signing-time attribute to minimize the burden of switching over from RRDP to rsync. Additionally, this document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute. "A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI)", Job Snijders, Geoff Huston, 2024-01-29, This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the listed ASN produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by this AS. "Human Readable Validate ROA Payload Notation", Tim Bruijnzeels, Ties de Kock, Oliver Borchert, Di Ma, 2023-10-23, 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, 2024-01-09, 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, 2024-02-29, 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. Session Initiation Protocol Core (sipcore) ------------------------------------------ "SIP Call-Info Parameters for Rich Call Data", Chris Wendt, Jon Peterson, 2024-03-02, This document describes a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the calling party in order to provide to the called party a description of the caller or details about the reason for the call. RCD includes information about the caller beyond the telephone number such as a calling name, or a logo, photo, or jCard object representing the caller, which can help the called party decide whether to answer the phone. The elements defined for this purpose are intended to be extensible in order to accommodate related information about calls and to be compatible and complimentary with the STIR/PASSporT RCD framework. This document defines a new parameter ('call-reason') for the SIP Call-Info header field and also a new token ("rcd-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". Structured Email (sml) ---------------------- "Structured Email", Hans-Joerg Happel, 2024-03-04, This document specifies how a machine-readable version of the content of email messages can be added to those messages. "Structured Email: Use cases", Hans-Joerg Happel, 2024-02-13, This document collects and discusses use cases for "structured email" ([I-D.happel-structured-email-00]). Stub Network Auto Configuration for IPv6 (snac) ----------------------------------------------- "Automatically Connecting Stub Networks to Unmanaged Infrastructure", Ted Lemon, Jonathan Hui, 2024-03-04, This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). 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, 2024-02-20, 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, 2023-10-23, This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a 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, Zhuang Shunwan, Dan Voyer, Muhammad Durrani, Satoru Matsushima, Vishnu Beeram, 2024-03-04, This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. "YANG Data Model for SRv6 Base and Static", Syed Raza, Sonal Agarwal, Xufeng Liu, Zhibo Hu, Iftekhar Hussain, Himanshu Shah, Dan Voyer, Hani Elmalky, Satoru Matsushima, Katsuhiro Horiba, Jaganbabu Rajamanickam, Ahmed Abdelsalam, 2024-03-04, This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, Jiang Wenying, 2024-01-27, Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path (LSP) Ping to bootstrap a BFD session, optional control of the selection of a segment list as the reverse direction of the BFD session, applicability of BFD Demand mode, and Seamless BFD in the SR-MPLS domain. Also, the document describes the use of the BFD Echo function with the BFD Control packet payload. "Segment Protection for SR-TE Paths", Shraddha Hegde, Chris Bowers, Stephane Litkowski, Xiaohu Xu, Feng Xu, 2024-02-09, Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. "Path Segment for SRv6 (Segment Routing in IPv6)", Cheng Li, Weiqiang Cheng, Mach Chen, Dhruv Dhody, Yongqing Zhu, 2023-10-19, 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 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 Path Segment 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, 2024-03-03, 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". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, 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, Dan Voyer, Mach Chen, Richard Foote, 2024-03-04, Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The procedure described is used for links, end-to-end SR paths (including SR Policies and SR Flexible Algorithm IGP paths) as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. "SRv6 for Redundancy Protection", Xuesong Geng, Mach Chen, Fan Yang, Pablo Camarillo, Gyan Mishra, 2024-01-17, Redundancy Protection is a generalized protection mechanism to achieve high reliability of service transmission in Segment Routing network. The mechanism uses the "Live-Live" methodology, with the aim of enhancing the functionalities of Segment Routing over IPv6. Inspired by DetNet Packet Replication and Packet Elimination functions, this document introduces two new Segments to provide replication and elimination functions on specific network nodes by leveraging SRv6 Segment programming capabilities. "Compressed SRv6 Segment List Encoding", Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Bruno Decraene, Francois Clad, 2024-03-18, Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SR segment 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. "Circuit Style Segment Routing Policies", Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone, 2023-10-23, 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 segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). "Distribute SRv6 Locator by DHCP", Weiqiang Cheng, Ruibo Han, Changwang Lin, Yuanxiang Qiu, Geng Zhang, 2023-11-06, In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned a locator, and segment IDs are generated within the address space of this locator. This document describes a method for assigning locators to SRv6 Segment Endpoint Nodes through DHCPv6. Secure Telephone Identity Revisited (stir) ------------------------------------------ "OCSP Usage for Secure Telephone Identity Certificates", Jon Peterson, Sean Turner, 2024-03-17, 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, 2023-10-23, The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a 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, 2023-10-23, 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, 2024-02-05, 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 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, 2024-03-03, 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, 2024-03-04, 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, 2024-03-04, This specification describes extensions to the SUIT manifest format defined in [I-D.ietf-suit-manifest]. 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, 2024-03-04, This specification describes extensions to the SUIT Manifest format (as defined in [I-D.ietf-suit-manifest]) 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, 2024-03-04, 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. "Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests", Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto, 2024-02-12, This document specifies algorithm profiles for SUIT manifest parsers and authors to ensure better interoperability. These profiles apply specifically to a constrained node software update use case. Thing-to-Thing (t2trg) ---------------------- "Guidance on RESTful Design for Internet of Things Systems", Ari Keranen, Matthias Kovatsch, Klaus Hartke, 2024-01-25, 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). "IoT Edge Challenges and Functions", Jungha Hong, Yong-Geun Hong, Xavier de Foy, Matthias Kovatsch, Eve Schooler, Dirk Kutscher, 2023-09-15, Many Internet of Things (IoT) applications have requirements that cannot be satisfied by traditional cloud-based systems (i.e., cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, IoT is driving the Internet toward edge computing. This document outlines the requirements of the emerging IoT Edge and its challenges. It presents a general model and major components of the IoT Edge to provide a common basis for future discussions in the T2TRG and other IRTF and IETF groups. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). "Amplification Attacks Using the Constrained Application Protocol (CoAP)", John Mattsson, Goeran Selander, Christian Amsuess, 2024-02-21, Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Michael Richardson, 2024-01-30, 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. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations "Terminology and processes for initial security setup of IoT devices", Mohit Sethi, Behcet Sarikaya, Dan Garcia-Carrillo, 2023-09-25, 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. Transport Services (taps) ------------------------- "Architecture and Requirements for Transport Services", Tommy Pauly, Brian Trammell, Anna Brunstrom, Gorry Fairhurst, Colin Perkins, 2023-11-09, This document describes an architecture for exposing transport protocol features to applications for network communication. This system exposes transport protocol features to applications for network communication. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. This API uses messages for representing data transfer to applications, and describes how a Transport Services Implementation can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document provides the architecture and requirements. It defines common terminology and concepts to be used in definitions of a Transport Service API and a Transport Services Implementation. "An Abstract Application Layer Interface to Transport Services", Brian Trammell, Michael Welzl, Reese Enghardt, Gorry Fairhurst, Mirja Kuehlewind, Colin Perkins, Philipp Tiesel, Tommy Pauly, 2024-03-16, This document describes an abstract application programming interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services architecture by providing asynchronous, atomic transmission of messages. It is intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols. "Implementing Interfaces to Transport Services", Anna Brunstrom, Tommy Pauly, Reese Enghardt, Philipp Tiesel, Michael Welzl, 2023-12-14, The Transport Services system enables applications to use transport protocols flexibly for network communication and defines a protocol- independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementing such a system. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "More Accurate Explicit Congestion Notification (ECN) Feedback in TCP", Bob Briscoe, Mirja Kuehlewind, Richard Scheffenegger, 2023-11-17, 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 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 exploited to feed back the IP-ECN field received during the 3-way handshake as well. 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, 2023-12-02, 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. "A YANG Model for Transmission Control Protocol (TCP) Configuration and State", Michael Scharf, Mahesh Jethanandani, Vishal Murgai, 2022-09-11, This document specifies a minimal YANG model for TCP on devices that are configured and managed by network management protocols. The YANG model defines a container for all TCP connections, and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). "Proportional Rate Reduction for TCP", Matt Mathis, Nandita Dukkipati, Yuchung Cheng, Neal Cardwell, 2024-03-16, This document updates the experimental Proportional Rate Reduction (PRR) algorithm, described RFC 6937, to standards track. PRR provides logic to regulate 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, 2024-03-02, 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. Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------- "A YANG Data Model for Resource Reservation Protocol (RSVP)", Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin, 2024-02-28, This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features. "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2024-02-02, 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. "The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC).", Zhenbin Li, Dhruv Dhody, Quintin Zhao, Zekung Ke, Boris Khasanov, 2023-01-08, The Path Computation Element (PCE) is a core component of a Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and update paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a much broader applicability than signal MPLS traffic- engineered (TE) paths, and the PCE may be used to determine paths in a range of use cases including static LSPs, Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE as a 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. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions which required for the PCECC use cases are covered in separate documents. "A YANG Data Model for requesting path computation", Italo Busi, Sergio Belotti, Oscar de Dios, Anurag Sharma, Yan Shi, 2024-02-14, 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. "YANG Data Model for SR and SR TE Topologies on MPLS Data Plane", Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Himanshu Shah, Stephane Litkowski, 2023-10-21, This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) traffic engineering (TE) topology, using MPLS data plane. "YANG Data Model for Layer 3 TE Topologies", Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Himanshu Shah, Oscar de Dios, 2024-03-02, This document defines a YANG data model for layer 3 traffic engineering topologies. "A YANG Data Model for Virtual Network (VN) Operations", Young Lee, Dhruv Dhody, Daniele Ceccarelli, Igor Bryskin, Bin Yoon, 2024-03-16, A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per Abstraction and Control of TE Networks (ACTN) framework. "SF Aware TE Topology YANG Model", Igor Bryskin, Xufeng Liu, Young Lee, Jim Guichard, Luis Contreras, Daniele Ceccarelli, Jeff Tantsura, Dmytro Shytyi, 2023-11-08, This document describes a YANG data model for TE network topologies that are network service and function aware. "A Framework for NRP-based Enhanced Virtual Private Network", Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka, Young Lee, 2023-12-25, This document describes the framework for NRP-based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work. "Traffic Engineering (TE) and Service Mapping YANG Data Model", Young Lee, Dhruv Dhody, Giuseppe Fioccola, Qin WU, Daniele Ceccarelli, Jeff Tantsura, 2024-03-16, 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 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 resource and TE models. "Interworking of GMPLS Control and Centralized Controller Systems", Haomian Zheng, Yi Lin, Yang Zhao, Yunbin Xu, Dieter Beller, 2024-02-08, Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issues from multi- domain, multi-vendor, and multi-technology. An example of such centralized architecture is Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy described in RFC 8453. Instead of competing with each other, both the distributed and the centralized control plane have their own advantages, and should be complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network. "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Young Lee, Dhruv Dhody, Ricard Vilalta, Daniel King, Daniele Ceccarelli, 2024-03-16, This document provides YANG data models that describe performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). There 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, 2024-02-22, This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing", Daniel King, John Drake, Haomian Zheng, Adrian Farrel, 2024-03-17, 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, 2024-03-16, 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, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil, 2023-11-26, 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, 2024-02-22, This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model 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, 2024-03-04, 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 XXXX 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, 2023-10-23, 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 slices have 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 management plane, control plane and data plane. "A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies", Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras, 2024-02-28, 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, Dhruv Dhody, Sergio Belotti, 2023-10-23, This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of 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, 2024-03-16, RFC 9543 describes a framework for Network Slice in a network 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, 2024-03-18, 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. 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, 2023-11-06, 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", Penglin Yang, Meiling Chen, Li Su, Ting Pang, 2024-02-21, 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 and other scenarios to use confidential computing in network. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages", Douglas Arnold, Heiko Gerstung, 2023-11-23, This document describes a PTP Profile for the use of the Precision Time Protocol in an IPv4 or IPv6 Enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allows both multicast and unicast Delay Request and Delay Response messages. Transport Layer Security (tls) ------------------------------ "TLS Encrypted Client Hello", Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher Wood, 2024-03-04, 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, 2024-03-16, 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. "Compact TLS 1.3", Eric Rescorla, Richard Barnes, Hannes Tschofenig, Benjamin Schwartz, 2023-10-23, This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. "The Transport Layer Security (TLS) Protocol Version 1.3", Eric Rescorla, 2024-03-03, 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, 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, 2023-10-09, 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, 2024-01-23, 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. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. "Deprecating Obsolete Key Exchange Methods in TLS 1.2", Carrick Bartle, Nimrod Aviram, 2023-09-21, 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 [RFC8996] and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. "A well-known URI for publishing ECHConfigList values.", Stephen Farrell, Rich Salz, Benjamin Schwartz, 2023-10-22, We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about this origin's Service Bindings, i.e. its "HTTPS" DNS records. These instructions can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. "Abridged Compression for WebPKI Certificates", Dennis Jackson, 2024-03-16, This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2023-09-26, 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 record. "TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key", Russ Housley, 2024-01-09, This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with a combination of a certificate and an external pre-shared key (PSK). "Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3", David Benjamin, Andrei Popov, 2023-11-30, 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, 2024-01-24, A format that supports the 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. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support", Donald Eastlake, Bob Briscoe, 2018-02-25, Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). Transport and Services Working Group (tsvwg) -------------------------------------------- "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Bob Briscoe, John Kaippallimalil, 2023-12-05, The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ECN in Section 13 of RFC 3819, by replacing it with a reference to the whole of this document. "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", Bob Briscoe, 2023-12-05, RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. "Transport Options for UDP", Joseph Touch, 2024-03-04, Transport protocols are extended through the use of transport header options. This document extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services", Greg White, Thomas Fossati, Ruediger Geib, 2024-02-16, 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. [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, 2024-03-17, This document is intended to provide 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 link. 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. "Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP)", Magnus Westerlund, John Mattsson, Claudio Porfiri, 2023-10-23, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). It is an improved alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and partial replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an improved alternative to RFC 6083 and removes the 16 kbytes limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of security fixes and improvements. It updates the DTLS versions and SCTP-AUTH HMAC algorithms to use. It mitigates reflection attacks of data and control chunks and replay attacks of data chunks. It simplifies secure implementation by some stricter requirements on the establishment procedures as well as rekeying to align with zero trust principles. "DCCP Extensions for Multipath Operation with Multiple Addresses", Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson, 2024-03-16, DCCP communications as defined in [RFC4340] are restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of available multiple paths for a DCCP session could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failures. Use cases for Multipath DCCP (MP- DCCP) are mobile devices (e.g., handsets, vehicles) and residential home gateways simultaneously connected to distinct networks as, e.g., a cellular and a Wireless Local Area (WLAN) network or a cellular and a fixed access network. Compared to the existing multipath protocols, such as MPTCP, MP-DCCP provides specific support for non- TCP user traffic (e.g., UDP or plain IP). This document specifies a set of extensions to DCCP to support multipath operations. Multipath DCCP provides the ability to simultaneously use multiple paths between peers. The protocol offers the same type of service to applications as DCCP and provides the components necessary to establish and use multiple DCCP flows across different paths simultaneously. "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2024-01-04, 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 the 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. "Zero Checksum for the Stream Control Transmission Protocol", Michael Tuexen, Victor Boivie, Florent Castelli, Randell Jesup, 2024-02-20, The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP provides already the same or a higher level of data integrity, computing this checksum does not provide any additional protection, but does consume computing resources. This document provides a simple extension to SCTP allowing to save these computing resources by using zero as the checksum in a backwards compatible way. It also defines how this feature can be used when SCTP packets are encapsulated in Datagram Transport Layer Security (DTLS) packets. "Convergence of Congestion Control from Retained State", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Raffaello Secchi, Christian Huitema, 2024-02-16, This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections. It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are stored, allowing them to be later used to modify the congestion control behavior of a subsequent connection. It describes assumptions and defines requirements for how a sender utilizes these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilize available capacity. It discusses how use of the method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig, 2024-03-04, 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. Time-Variant Routing (tvr) -------------------------- "TVR (Time-Variant Routing) Use Cases", Edward Birrane, Nicolas Kuhn, Yingzhen Qu, Rick Taylor, Li Zhang, 2024-02-29, This document introduces use cases where Time-Variant Routing (TVR) computations (i.e. routing computations taking into considerations time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance. "TVR (Time-Variant Routing) Requirements", Daniel King, Luis Contreras, Brian Sipos, 2024-03-04, Time-Variant Routing (TVR) refers to the calculation of 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. Using TLS in Applications (uta) ------------------------------- "TLS/DTLS 1.3 Profiles for the Internet of Things", Hannes Tschofenig, Thomas Fossati, Michael Richardson, 2024-03-03, This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile. 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. "Updates to the Cipher Suites in Secure Syslog", Chris Lonvick, Sean Turner, Joseph Salowey, 2023-09-21, The Syslog Working Group published two specifications, namely RFC 5425 and RFC 6012, for securing the Syslog protocol using TLS and DTLS, respectively. This document updates the cipher suites in RFC 5425, Transport Layer Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. It also updates the transport protocol in RFC 6012. Revise Universally Unique Identifier Definitions (uuidrev) ---------------------------------------------------------- "Universally Unique IDentifiers (UUID)", Kyzer Davis, Brad Peabody, P. Leach, 2023-11-06, This specification defines the UUIDs (Universally Unique IDentifiers) and the UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. This document obsoletes RFC4122. IPv6 Operations (v6ops) ----------------------- "Operational Issues with Processing of the Hop-by-Hop Options Header", Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra, 2024-02-16, This document describes the processing of the Hop-by-Hop Options Header (HBH) in current routers in the aspects of standards specification, common implementations, and default operations. This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how HBH Options Header could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The purpose of this draft is to document reasons why HBH Options Header is rarely used within networks. It motivates the benefits and requirements needed to enable wider use of HBH Options. "Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Issues and Simplify IPv6 First-hops", XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, Nick Buraglio, 2024-03-04, Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses multicast extensively and trusts all hosts. In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable. Consequently, ND has potential issues in various scenarios. The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview is useful. This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference. Analyzing these solutions reveals an insight: isolating hosts is effective in preventing ND issues. Five isolation methods are proposed and their applicability is discussed. Guidelines are described for selecting a suitable isolation method based on the deployment scenario. When ND issues are prevented with a proper isolation method, the solutions for these issues are not needed. This simplifies the IPv6 first- hops. "Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service", Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Mohamed Boucadair, Thomas Graf, 2024-02-04, For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 service(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in one multi- domain underlay network. It lists the requirements of service traffic, illustrates major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery. The document also discusses related security considerations. "Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks", Lorenzo Colitti, Jen Linkova, Xiao Ma, 2024-02-26, This document discusses an IPv6 deployment scenario when individual clients connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD). "Expanding the IPv6 Documentation Space", Geoff Huston, Nick Buraglio, 2023-11-14, The document describes the reservation of an additional IPv6 address prefix for use in documentation. The reservation of a /20 prefix allows documented examples to reflect a broader range of realistic current deployment scenarios. "IPv6-only Capable Resolvers Utilising NAT64", Momoka Yamamoto, Yasunobu Toyota, 2023-10-23, This document outlines how IPv6-only iterative resolvers can use stateful NAT64 to establish communications with IPv4-only authoritative servers. It outlines a mechanism for translating the IPv4 addresses of authoritative servers to IPv6 addresses to initiate communications. Through the mechanism of IPv4-to-IPv6 address translation, these resolvers can operate in an IPv6-only network environment. "IPv6 CE Routers LAN Prefix Delegation", Timothy Winters, 2024-03-02, This document defines requirements for IPv6 CE Routers to support DHCPv6 Prefix Delegation for redistributing any unused prefix(es) that were delegated to the IPv6 CE Router. This document updates RFC 7084. WebTransport (webtrans) ----------------------- "The WebTransport Protocol Framework", Victor Vasiliev, 2024-03-04, 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, 2024-03-04, 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, 2024-03-04, 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. WebRTC Ingest Signaling over HTTPS (wish) ----------------------------------------- "WebRTC-HTTP ingestion protocol (WHIP)", Sergio Murillo, Alex Gouaillard, 2024-02-07, This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This document updates RFC 8842 and RFC 8840. "WebRTC-HTTP Egress Protocol (WHEP)", Sergio Murillo, Cheng Chen, 2024-03-18, This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs).