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 drafts are listed alphabetically by working group acronym and start date. Generated 2022-12-07 13:05:36 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "Transmission of IPv6 Packets over Near Field Communication", Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, 2022-11-17, Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LoWPAN techniques. "IPv6 over Constrained Node Networks (6lo) Applicability & Use cases", Yong-Geun Hong, Carles Gomez, Younghwan Choi, Abdur Sangi, Samita Chakrabarti, 2022-10-24, This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC, and PLC are used as examples. The document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained node networks for local or Internet connectivity. "Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2022-05-18, Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. "IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription", Pascal Thubert, 2022-11-22, This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address; the document updates RPL (RFC 6550) 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. IPv6 Maintenance (6man) ----------------------- "IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fengwei Qin, Ran Pang, 2022-09-27, This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate Marking information in both the Hop-by-Hop Options Header and Destination Options Header. "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson, 2022-08-12, In renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios. "IPv6 Hop-by-Hop Options Processing Procedures", Robert Hinden, Gorry Fairhurst, 2022-10-21, This document specifies procedures for how IPv6 Hop-by-Hop options are processed. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing of IPv6 Hop-by- Hop options 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 and RFC7045. "Limits on Sending and Processing IPv6 Extension Headers", Tom Herbert, 2022-10-23, 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 and thereby increasing the feasibility of deployment of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers in the Internet. If it is known that all communicating parties for a particular commumication, including end hosts and any intermediate nodes in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. "Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header", Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma, Gyan Mishra, 2022-10-24, Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction and evolvement of 5G and other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional VPNs. Such kind of network service is called enhanced VPNs (VPN+). VPN+ can be used to deliver IETF network slices, and could also be used for other application scenarios. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN related information, which could used to identify the set of network resources allocated to a VTN and the rules for packet processing. The procedure of processing the VTN option is also specified. "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", Brian Carpenter, Stuart Cheshire, Robert Hinden, 2022-11-06, 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. "Segment Identifiers in SRv6", Suresh Krishnan, 2022-10-11, 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 to clarify the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Key Provisioning for Group Communication using ACE", Francesca Palombini, Marco Tiloca, 2022-09-05, 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, 2022-09-05, 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. "Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework", Cigdem Sengul, Anthony Kirby, 2022-03-23, This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in a Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, 2022-10-24, 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. 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. "CoAP Transfer for the Certificate Management Protocol", Mohit Sahni, Saurabh Tripathi, 2022-09-19, This document specifies the use of Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the IoT space. "EAP-based Authentication Service for CoAP", Rafael Marin-Lopez, Dan Garcia-Carrillo, 2022-06-23, 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), enable 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, Ludwig Seitz, Francesca Palombini, Sebastian Echeverria, Grace Lewis, 2022-10-24, 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. The method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server, with the possible additional use of resource observation for the Constrained Application Protocol (CoAP). Resulting (unsolicited) notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. "Extension of the CoAP-DTLS Profile for ACE to TLS", Olaf Bergmann, John Mattsson, Goeran Selander, 2022-09-21, This document updates the CoAP-DTLS profile for ACE by specifying that the profile applies to TLS as well as DTLS. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ace/. Source for this draft and an issue tracker can be found at https://github.com/ace-wg/ace-extend-dtls-authorize. "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, 2022-11-11, 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 OAuth 2.0 Client and Resource Server, and it binds an authentication credential of the Client to an OAuth 2.0 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. A resource-constrained server can use this profile to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. Automated Certificate Management Environment (acme) --------------------------------------------------- "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock, Mary Barnes, Jon Peterson, 2022-12-05, This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates. "ACME Challenges Using an Authority Token", Jon Peterson, Mary Barnes, David Hancock, Chris Wendt, 2022-10-24, Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. "ACME Integrations", Owen Friel, Richard Barnes, Rifaat Shekh-Yusef, Michael Richardson, 2022-09-30, 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, 2022-09-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. 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". "ACME for Subdomains", Owen Friel, Richard Barnes, Tim Hollebeek, Michael Richardson, 2022-06-29, This document outlines how ACME can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. The client has fulfilled a challenge against a parent domain but does not need to fulfill a challenge against the explicit subdomain as certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. "Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension", Aaron Gable, 2022-08-25, 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. Current Implementations Draft note: this section will be removed by the editor before final publication. Let's Encrypt's Staging environment (available at [lestaging], source at [boulder]) implements this draft specification. Adaptive DNS Discovery (add) ---------------------------- "Discovery of Designated Resolvers", Tommy Pauly, Eric Kinnear, Christopher Wood, Patrick McManus, Tommy Jensen, 2022-08-05, This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An encrypted DNS resolver discovered in this manner is referred to as a "Designated Resolver". This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted DNS resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted DNS resolver is known. "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook, Tommy Jensen, 2022-08-13, The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows a host to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. "Service Binding Mapping for DNS Servers", Benjamin Schwartz, 2022-08-11, The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. "Establishing Local DNS Authority in Split-Horizon Environments", Tirumaleswar Reddy.K, Dan Wing, Kevin Smith, Benjamin Schwartz, 2022-11-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 don't always use this resolver might wish to do so for these domains. This specification describes how clients can confirm the local resolver's authority over these domains. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Performance Cost Metrics", Qin WU, Y. Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, Luis Contreras, 2022-03-21, The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used. This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a, jitter), packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimation based on measurements or service-level agreement) to derive a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. "A Yang Data Model for OAM and Management of ALTO Protocol", Jingxuan Zhang, Dhruv Dhody, Kai Gao, Roland Schott, 2022-10-24, This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of Application- Layer Traffic Optimization (ALTO) Protocol. The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data. "ALTO New Transport: ALTO Transport Information Structures", Roland Schott, Y. Yang, Kai Gao, Jingxuan Zhang, 2022-10-21, The ALTO base protocol [RFC7285] defines both the ALTO information resources and their transport from the server to the client. Using HTTP/1.x as the transport protocol, the ALTO transport in the base protocol includes the limitations of HTTP/1.x. ALTO/SSE [RFC8895] defines a new transport design addressing some of the limitations, but is still based on HTTP/1.x. This document introduces ALTO new transport, which introduces ALTO transport information structures (TIS) at an ALTO server. The introduction of ALTO TIS allows at least two types of efficient transport using HTTP: (1) HTTP/2/3 independent client (long) pull allowed by non-blocking, newer HTTP, and (2) HTTP/2 specific server push. This document defines ALTO TIS and the first design. A companion document [draft-schott-alto-new-transport-push] defines server-push ALTO transport based on ALTO TIS. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)", Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk, 2022-07-11, This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping 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. Constrained BRSKI 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 is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher 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 CoAPS. "Information Distribution over GRASP", Xun Xiao, Bing Liu, Artur Hecker, Sheng Jiang, 2022-07-10, Autonomic network infrastructure (ANI) is a generic platform for tenant applications (i.e. AFs). As we will see in some examplery use cases, AFs may not only require communication capability supported from the infrastructure side, but also the capability the infrastructure can hold and re-distribute information on-demand. This document proposes a set of solutions for information distribution in the ANI. Information distribution is categorized into two different modes: 1) instantaneous distribution and 2) publishing for retrieval. In the former case, the information is sent, propagated and disposed of after reception. In the latter case, information needs to be stored in the network; additionally, conflict resolution is also needed when information stored in the network is updated with proposals from two different AFs. The capability of information distribution is a fundamental need for an autonomous network ([RFC7575]). This document describes typical use cases of information distribution in ANI and requirements to ANI, such that abundant ways of information distribution can be natively supported. This draft proposes a series of extensions to the autonomic nodes and suggests an implementation based on GRASP ([RFC8990]) extensions as a protocol on the wire. "Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2022-10-23, This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the (stateful) TLS Circuit proxy between Pledge and Registrar with a stateless or stateful Circuit proxy using CoAP which is called the 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. Like the BRSKI Circuit proxy, this constrained Join Proxy eliminates the need of Pledges to have routeable IP addresses before enrolment by utilizing link-local addresses. Use of the constrained Join Proxy also eliminates the need of the Pledge to authenticate to the network or perform network-wide Registrar discover before enrolment. "Delegated Authority for Bootstrap Voucher Artifacts", Michael Richardson, Wei Pan, 2022-07-11, This document describes an extension of the RFC8366 Voucher Artifact in order to support delegation of signing authority. The initial voucher pins a public identity, and that public indentity can then issue additional vouchers. This chain of authorization can support permission-less resale of devices, as well as guarding against business failure of the BRSKI Manufacturer Authorized Signing Authority (MASA). "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael Richardson, 2022-11-13, This document specifies the behavior of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud "JWS signed Voucher Artifacts for Bootstrapping Protocols", Thomas Werner, Michael Richardson, 2022-10-24, [RFC8366] defines a digital artifact called voucher as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. This memo introduces a variant of the voucher structure 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, MIME types are registered and examples are provided. "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson, 2022-10-24, This document defines enhancements to bootstrapping a remote secure key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in domains featuring no or only time limited connectivity between a pledge and the domain registrar. It specifically targets situations, in which the interaction model changes from a pledge-initiated-mode, as used in BRSKI, to a pledge-responding-mode as described in this document. To support the pledge-responding mode, BRSKI-PRM introduces a new component, the registrar-agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establishment the trust relation between pledge and domain registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic with respect to the underlying enrollment protocol which connects the pledge and the domain registrar to the Domain CA. "A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services", Yujing Zhou, Joanna Dang, Sheng Jiang, Zongpeng Du, 2022-10-24, This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) defined in [RFC8990] 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. "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", David von Oheimb, Steffen Fries, Hendrik Brockhaus, 2022-10-24, This document enhances Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) to allow employing alternative enrollment protocols, such as CMP. Using self-contained signed objects, the origin of enrollment requests and responses can be authenticated independently of message transfer. This supports end-to-end security and asynchronous operation of certificate enrollment and provides flexibility where to authenticate and authorize 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. "The LIMITS SMTP Service Extension", Ned Freed, John Klensin, 2022-11-09, This document defines a "Limits" extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. This extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits. "WebP Image Format", James Zern, Pascal Massimino, Jyrki Alakuijala, 2022-12-02, This document defines the WebP image format and registers a media type supporting its use. "Updated Use of the Expires Message Header Field", Benjamin BILLON, John Levine, 2022-11-22, This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message sent becomes valueless and can safely be deleted, while recipients would use the information to delete or ignore these valueless messages. Automatic SIP trunking And Peering (asap) ----------------------------------------- "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2022-10-17, This draft specifies a configuration workflow to enable enterprise Session Initiation Protocol (SIP) networks to solicit the capability set of a SIP service provider network. The capability set can subsequently be used to configure features and services on the enterprise edge element, such as a Session Border Controller (SBC), to ensure smooth peering between enterprise and service provider networks. "The 'sip-trunking-capability' Link Relation Type", Kaustubh Inamdar, Sreekanth Narayanan, Derek Engi, Gonzalo Salgueiro, 2022-11-07, This specification defines the 'sip-trunking-capability' link relation type that may be used for the retrieval of capabilities and configuration requirements from Internet Telephony Service Providers (ITSPs). A Session Initiation Protocol (SIP) trunking capability set is defined to allow the transfer of technical requirements needed for seamless peering between SIP-based enterprise telephony networks and ITSPs where an exchange of parameters and configuration information is required. 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, 2022-06-30, 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. An SDF specification describes definitions of SDF Objects 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. // A JSON format representation of SDF 1.0 was defined in version // (-00) of this document; version (-05) was designated as an // _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of // the ASDF WG (2021-03-11). The present version (-12) collects // smaller changes up to 2022-06-30. It also removes deprecated // elements from SDF 1.0. 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. "Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas Nandakumar, 2021-11-11, This document describes a 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 Versatile Video Coding (VVC)", Shuai Zhao, Stephan Wenger, Yago Sanchez, Ye-Kui Wang, Miska Hannuksela, 2022-08-04, This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3, both also known as Versatile Video Coding (VVC) and developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. "Multiplexing Scheme Updates for QUIC", Bernard Aboba, Gonzalo Salgueiro, Colin Perkins, 2022-08-05, This document defines how QUIC, Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. This document updates RFC 7983 and RFC 5764. "Completely Encrypting RTP Header Extensions and Contributing Sources", Justin Uberti, Cullen Jennings, Sergio Murillo, 2022-08-04, While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. "RTP Payload Format for Visual Volumetric Video-based Coding (V3C)", Lauri Ilola, Lukasz Kondrad, 2022-06-27, 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 appropriate Internet Standards for the applicable video codec. The RTP payload format for V3C atlas sub-bitstreams is described by this memo. The RTP payload format allows for packetization of one or more V3C Network Abstraction Layer (NAL) units in a RTP packet payload as well as fragmentation of a V3C 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 bitstream. "RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec", Daniel Hanson, MikeFaller, Keith Maver, 2022-11-17, This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an application layer protocol that defines the establishment of reliable secure end-to-end communications, including capabilities exchange with secure session establishment parameters such as codec selection, encryption algorithms, security levels, and cryptographic initialization values. This document defines the Session Description Protocol (SDP) and RTP parameters needed to support SCIP over RTP. "RTP over QUIC", Joerg Ott, Mathis Engelbart, 2022-10-24, This document specifies a minimal mapping for encapsulating RTP and RTCP packets within QUIC. It also discusses how to leverage state from the QUIC implementation in the endpoints to reduce the exchange of RTCP packets and how to implement congestion control. 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. "Relaxed Packet Counter Verification for Babel MAC Authentication", Juliusz Chroboczek, Toke Hoeiland-Joergensen, 2022-11-29, This document relaxes packet verification rules defined in the Babel MAC Authentication protocol in order to make it more robust in the presence of packet reordering. 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, 2022-09-02, The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast 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, Service Providers 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. "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2022-11-28, 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, 2022-08-24, The Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying Highest Random Weight (HRW) Algorithm for Designated Forwarded election in order to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder (DF) election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. The solution is independent of the number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each of the other PEs in the multihoming group. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan, 2021-07-06, EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions introduce Single-Active and All-Active 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 EVCs (e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), 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, 2022-11-28, EVPN enables all-active multi-homing for a CE device connected to two or more PEs via a LAG, 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. "MVPN/EVPN Tunnel Aggregation with Common Labels", Zhaohui Zhang, Eric Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands, 2022-01-20, The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple 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, 2022-07-06, 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 1, 128 and EVPN IP Prefix routes, and therefore this document updates [RFC4271]. "Extended Mobility Procedures for EVPN-IRB", Neeraj Malhotra, Ali Sajassi, Aparna Pattekar, Jorge Rabadan, Avinash Lingala, John Drake, 2022-11-28, Procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC 7432. 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 RFC 7432 are extensible to IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed across VM moves. Generic mobility support for IP and MAC that allows these bindings to change across moves is required to support a broader set of EVPN IRB use cases, and requires further consideration. 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 defines generic sequence number assignment procedures to address these IRB use cases. "LSP-Ping Mechanisms for EVPN and PBB-EVPN", Parag Jain, Ali Sajassi, Samer Salam, Sami Boutros, Greg Mirsky, 2022-07-08, LSP Ping is a widely deployed Operation, Administration, and Maintenance mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. "EVPN control plane for Geneve", Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan, Sam Aldrin, 2022-11-23, This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by Network Virtualization Edges (NVEs) to express Geneve tunnel option TLV(s) supported in the transmission and/or reception of Geneve encapsulated data packets. "PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Masahiro Miyake, Taku Matsuda, 2022-06-23, Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large Multi-Protocol Label Switching (MPLS) networks (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, PBB-EVPN defines a flush mechanism for Customer MACs (CMAC-flush) that works for different Ethernet Segment Backbone MAC (BMAC) address allocation models. This document complements those CMAC-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) CMAC-flush granularity is required. "Seamless Multicast Interoperability between EVPN and MVPN PEs", Ali Sajassi, Kesavan Thiruvenkatasamy, Samir Thoria, Ashutosh Gupta, Luay Jalil, 2022-06-28, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) networks and 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. "EVPN multi-homing port-active load-balancing", Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan, 2022-10-05, The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The 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 load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support for port-active load-balancing mode. "Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin, Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2022-07-08, [EVPN-AR] specifies an optimized ingress replication solution for more efficient multicast and broadcast delivery in a Network Virtualization Overlay (NVO) network for EVPN. This document extends the optimized ingress replication procedures specified in [EVPN-AR] to overcome the limitation that an AR- REPLICATOR may have. An AR-REPLICATOR may be unable to retain the source IP address or include the expected ESI label that is required for EVPN split horizon filtering when replicating the packet on behalf of its multihomed AR-LEAF. Under this circumstance, the extended procedures specified in this document allows the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN overlay network. "BGP Usage for SDWAN Overlay Networks", Linda Dunbar, Jim Guichard, Ali Sajassi, John Drake, Basil Najem, David Carrel, 2022-10-10, The document discusses the usage and applicability of BGP as the control plane for multiple SDWAN scenarios. The document aims to demonstrate how the BGP-based control plane is used for large-scale SDWAN overlay networks with little manual intervention. SDWAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers. "EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan, Kiran Nagaraj, Wen Lin, Ali Sajassi, 2022-06-23, 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 others, 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 extends the EVPN Multi-Homing procedures 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, 2022-07-02, A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. "BGP MPLS-Based Ethernet VPN", Ali Sajassi, Luc Burdet, John Drake, Jorge Rabadan, 2022-09-18, This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in [RFC7209] -- "Requirements for Ethernet VPN (EVPN)". Note to Readers _RFC EDITOR: please remove this section before publication_ The complete and detailed set of all changes between this version and [RFC7432] may be found as an Annotated Diff (rfcdiff) here (https://tools.ietf.org/rfcdiff?url1=https://www.rfc- editor.org/rfc/rfc7432.txt&url2=https://www.ietf.org/archive/id/ draft-ietf-bess-rfc7432bis-05.txt). "Multicast Source Redundancy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Wen Lin, Eric Rosen, 2022-10-07, 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. "EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols", Patrice Brissette, Ali Sajassi, Luc Burdet, Dan Voyer, 2022-10-24, The existing EVPN multi-homing load-balancing modes defined are Single-Active and All-Active. Neither of these multi-homing mechanisms adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. These loop-preventing Layer-2 protocols require a new multi-homing mechanism defined in this document. "IPv6-Only PE Design for IPv4-NLRI with IPv6-NH", Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2022-09-24, 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) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv6-Only. This document details an important External BGP (eBGP) PE-CE Edge and Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing both IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session. The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this design change from a control plane perspective a single IPv6 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv6 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding. This document provides a much needed solution for Internet Exchange Point (IXP) that are facing IPv4 address depletion at large peering points. With this design, IXP can now deploy PE-CE IPv6-Only eBGP Edge or Inter-AS peering design to eliminate IPv4 provisioning at the Edge. This core and edge IPv6-Only peering design paradigm change can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides vendor specific test cases for the IPv6-Only peering 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 this new Best Current Practice for eBGP IPv6-Only Edge peering. As this issue with IXP IPv4 address depletion is a critical issue around the world, it is imperative for an immediate solution that can be implemented quickly. This Best Current Practice IPv6-only eBGP peering design specification will help proliferate IPv6-Only deployments at the eBGP Edge network peering points to starting immediately at a minimum with operators around the world using Cisco, Juniper, Arista, Nokia and Huawei. As other vendors start to implement this Best Current Practice, the IXP IPv4 address depletion gap will eventually be eliminated. "Cumulative DMZ Link Bandwidth and load-balancing", satyamoh@cisco.com, Arie Vayner, Akshay Gattani, Ajay Kini, 2022-12-06, The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination (which is in a different AS than the source) which is reachable via more than one path. 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 which employs multi-path. The link-bandwidth value is then extracted from the path extended community and is used as a weight in the 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, Patrice Brissette, Mankamana Mishra, Samir Thoria, Jorge Rabadan, John Drake, 2022-11-21, EVPN provides an extensible and flexible multi-homing 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 IRB is one of the common deployment scenarios. There are deployments which requires capability to have multiple subnets designated with multiple VLAN IDs in 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 single Broadcast Domain. In this draft we define new service interface type to support multiple subnets in single Broadcast Domain. Service interface proposed in this draft will be applicable to multihoming case only. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Unsolicited BFD for Sessionless Applications", Enke Chen, Naiming Shen, Robert Raszuk, Reshad Rahman, 2022-11-12, For operational simplification of "sessionless" applications using Bidirectional Forwarding Detection (BFD), in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and established without explicit per- session configuration or registration by the other side (subject to certain per-interface or global policies). We also introduce a new YANG module to configure and manage "unsolicited BFD". The YANG module in this document is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. This document updates RFC 9314. "Unaffiliated BFD Echo", Weiqiang Cheng, Ruixue Wang, Xiao Min, Reshad Rahman, Raj Boddireddy, 2022-08-01, 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. 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, 2022-10-11, 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. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow, 2022-09-25, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "BGP Link-State extensions for BIER", Ran Chen, Zhaohui Zhang, Vengada Govindan, IJsbrand Wijnands, 2022-10-20, 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. "BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols", Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda) Wang, Zheng Zhang, Markus Stenberg, 2022-07-25, This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 2022-08-10, 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). "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, 2022-07-03, 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. "BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover", Zheng Zhang, Greg Mirsky, Quan Xiong, Yisong Liu, Huanan Li, 2022-10-17, 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, 2022-09-04, 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 RFC8296 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, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-07-29, This document describes OSPF extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. "IS-IS Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-08-02, This document describes IS-IS extensions for distributing BitPositions configured on the links in "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, 2022-07-05, This document describes OSPFv3 extensions for distributing BitPositions configured on the links in "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, 2022-09-19, 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 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, 2022-07-11, 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, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-07-24, BIER is a scalable multicast overlay [RFC8279] 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) ------------------------------- "Benchmarking Methodology for Network Security Device Performance", Balamuhunthan Balarajah, Carsten Rossenhoevel, bmonkman, 2022-10-22, This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW) and next-generation intrusion prevention systems (NGIPS). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFW and NGIPS. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security- centric network application use cases. As a result, this document makes RFC3511 obsolete. "Multiple Loss Ratio Search", Maciek Konstantynowicz, Vratko Polak, 2022-11-09, This document proposes improvements to [RFC2544] throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). The main objectives for MLRsearch are to minimize the total test duration, search for multiple loss ratios and improve results repeatibility and comparability. The main motivation behind MLRsearch is the new set of challenges and requirements posed by testing Network Function Virtualization (NFV) systems and other software based network data planes. MLRsearch offers several ways to address these challenges, giving user configuration options to select their way. "A YANG Data Model for Network Tester Management", Vladimir Vassilev, 2022-10-22, 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, 2022-10-19, 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 phases: the preliminary test phase and the real test phase. 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. Calendaring Extensions (calext) ------------------------------- "JSCalendar: Converting from and to iCalendar", Robert Stepanek, Michael Douglass, 2022-07-11, This document provides the required methods for converting JSCalendar from and to iCalendar. "Calendar subscription upgrades", Michael Douglass, 2022-10-21, 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, 2022-10-23, 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, 2022-11-25, 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, 2022-11-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, 2022-11-25, This document defines how to convert contact information defined in the JSContact specification from and to vCard. Note This note is to be removed before publishing as an RFC. The verbatim case-insensitive string rfc0000 in this document is a placeholder. It will be replaced with the RFC number of the JSContact specification. "JSCalendar: A JSON Representation of Calendar Data", Neil Jenkins, Robert Stepanek, 2022-10-27, This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. This specification obsoletes [RFC8984]. "iCalendar Format Extension for JSCalendar", Robert Stepanek, Michael Douglass, 2022-07-11, This document defines a set of new properties for iCalendar and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSCalendar and iCalendar formats, but the new definitions also aim to be useful within just the iCalendar format. "vCard Format Extension for JSContact", Robert Stepanek, Mario Loffredo, 2022-11-25, 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. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Packed CBOR", Carsten Bormann, 2022-07-24, 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 (-07) adds the concept of Tag Equivalence as // initially discussed at the CBOR Interim meeting 12 in 2022 and // further in PR #6, for discussion before and at IETF 114. "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", Carsten Bormann, Ben Gamari, Henk Birkholz, 2022-10-04, 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. It is intended as the reference document for the IANA registration of the CBOR tags defined. // The present version (-02) fills in proposals for all TBDs that // were outstanding. 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, 2022-11-23, 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, 2022-10-09, 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, 2022-07-10, 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. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "A Yang Data Model for WSON Tunnel", Young Lee, Haomian Zheng, Aihua Guo, Victor Lopez, Daniel King, Bin-Yeong Yoon, Ricard Vilalta, 2022-07-11, This document provides a YANG data model for WSON TE tunnel. "Transport Northbound Interface Applicability Statement", Italo Busi, Daniel King, Haomian Zheng, Yunbin Xu, 2022-07-04, This document provides an analysis of the applicability of the YANG models defined by the IETF (in particular in the Traffic Engineering Architecture and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) working groups) to support ODU transit services, transparent client services, and Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL) services over Optical Transport Network (OTN) in single and multi-domain network scenarios. This document also describes how existing YANG models can be used through several worked examples and JSON fragments. "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli, 2022-11-14, 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 NMDA-compliant. "A YANG Data Model for Microwave Topology", Jonas Ahlberg, Scott Mansfield, Min Ye, Italo Busi, Xi Li, Daniela Spreafico, 2022-10-21, This document defines three YANG data models to describe topologies of microwave/millimeter radio links and bandwidth availability for a link in general, as well as to reference interface management information from a termination point. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang. "Applicability of GMPLS for Beyond 100G Optical Transport Network", Qilei Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti, 2022-11-18, This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709. "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, 2022-07-01, 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.[ITU-T.G694.1] and its extensions. "A YANG model to manage the optical interface parameters for an external transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel, 2022-10-24, 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 by in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of 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, 2022-10-24, 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 Assigment (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, Francesco Lazzeri, 2022-07-10, 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. "A YANG Data Model for Layer 1 Types", Haomian Zheng, Italo Busi, 2022-11-23, This document defines a collection of common data types and groupings in the YANG data modeling language for use with layer 1 networks. These derived common types and groupings are intended to be imported by modules that specify OTN networks, such as topology, tunnel, client signal adaptation and service. "A YANG Data Model for Ethernet TE Topology", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2022-09-05, A transport network is a server-layer network to provide connectivity services to its client. In this draft the topology of Ethernet with TE is described with YANG data model. "A YANG Data Model for Flexi-Grid Tunnels", Universidad de Madrid, Daniel Burrero, Daniel King, Victor Lopez, Italo Busi, Sergio Belotti, Gabriele Galimberti, 2022-07-11, This document defines a YANG model for managing flexi-grid optical tunnels (media-channels), complementing the information provided by the flexi-grid topology model. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "Framework and Data Model for OTN Network Slicing", Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu, 2022-10-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 a YANG data model augmentation of the OTN topology model. 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, Haomian Zheng, Esther Le Rouzic, Aihua Guo, Daniel King, 2022-10-23, 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, Fan Yang, Xiaobing NIU, Luis Contreras, Xufeng Liu, 2022-06-28, 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, 2022-10-24, 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 Optical Networks", Italo Busi, Aihua Guo, Sergio Belotti, 2022-10-24, This document provides a mechanism to request path computation in Optical Networks (WSON and Flexi-grid) 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. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile, Sanjay Mishra, 2022-10-23, This document defines metadata objects to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines CDNI Metadata interface objects to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC 9115 allows delegating entity to remain in full control of the delegation and be able to revoke it any time and avoids the need to share private cryptographic key material between the involved entities. "Content Delivery Network Interconnection (CDNI) Footprint Types: Subdivision Code and Union", Nir Sopher, Sanjay Mishra, 2022-10-11, 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 the CDNI Metadata Footprint Types defined in RFC 8006. The Footprint Types defined in this document can be used for Footprint objects as part of the Metadata interface (MI) defined in RFC 8006 or the Footprint & Capabilities Advertisement interface (FCI) defined in RFC 8008. The document also updates RFC 9241 with relevant ALTO entity domain types. The defined Footprint Types are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition", Ori Finkelman, Sanjay Mishra, Nir Sopher, 2022-08-29, This document obsoletes RFC8007. This document describes the part of the 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 can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can 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, 2022-12-07, The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document defines metadata in 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, 2022-10-19, 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. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice, Jerome Martinez, 2022-12-05, 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, 2022-10-01, This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application. "Matroska Media Container Codec Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2022-12-04, 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, 2022-12-04, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. "Free Lossless Audio Codec", Martijn van Beurden, Andrew Weaver, 2022-10-23, This document defines the Free Lossless Audio Codec (FLAC) format. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals without needing to remove information in doing so (i.e. lossless). FLAC is free in the sense that its specification is open, its reference implementation is open- source and it is not encumbered by any known patent. 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, 2022-12-04, This document defines the Control Track usage found in the Matroska container. "Matroska Media Container Chapter Codecs Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2022-12-04, This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. Crypto Forum (cfrg) ------------------- "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2022-02-08, This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and SPAKE2 has a security proof. This document predated the CFRG PAKE competition and it was not selected, however, given existing use of variants in Kerberos and other applications it was felt publication was beneficial. Applications that need a symmetric PAKE (password authenticated key exchange) and where hashing onto an elliptic curve at execution time is not possible can use SPAKE2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin, Dimitrios Papadopoulos, Jan Vcelak, 2022-08-09, A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick Sullivan, Riad Wahby, Christopher Wood, 2022-06-15, This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Alex Davidson, Armando Faz-Hernandez, Nick Sullivan, Christopher Wood, 2022-11-28, An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "KangarooTwelve", =?utf-8?q?Beno=C3=AEt_Viguier?=, David Wong, Giles Van Assche, Quynh Dang, Joan Daemen, 2022-08-19, This document defines the KangarooTwelve eXtendable Output Function (XOF), a hash function with output of arbitrary length. It provides an efficient and secure hashing primitive, which is able to exploit the parallelism of the implementation in a scalable way. It uses tree hashing over a round-reduced version of SHAKE128 as underlying primitive. 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. "BLS Signatures", Dan Boneh, Sergey Gorbunov, Riad Wahby, Hoeteck Wee, Christopher Wood, Zhenfei Zhang, 2022-06-16, BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. "Additional Parameter sets for LMS Hash-Based Signatures", Scott Fluhrer, Quynh Dang, 2022-08-19, This note extends LMS (RFC 8554) by defining parameter sets by including additional hash functions. Hese include hash functions that result in signatures with significantly smaller 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. "Pairing-Friendly Curves", Yumi Sakemi, Tetsutaro Kobayashi, Tsunekazu Saito, Riad Wahby, 2022-11-06, Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. "CPace, a balanced composable PAKE", Michel Abdalla, Bjoern Haase, Julia Hesse, 2022-07-24, 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, is compatible with any cyclic group of prime- and non-prime order. "Usage Limits on AEAD Algorithms", Felix Guenther, Martin Thomson, Christopher Wood, 2022-07-11, An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. "The OPAQUE Asymmetric PAKE Protocol", Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood, 2022-07-06, 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. "The ristretto255 and decaf448 Groups", Henry de Valence, Jack Grigg, Mike Hamburg, Isis Lovecruft, George Tankersley, Filippo Valsorda, 2022-11-29, This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. "Two-Round Threshold Schnorr Signatures with FROST", Deirdre Connolly, Chelsea Komlo, Ian Goldberg, Christopher Wood, 2022-10-07, In this draft, we present the two-round signing variant of FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme. FROST signatures can be issued after a threshold number of entities cooperate to issue a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. Further, this draft specifies signatures that are compatible with [RFC8032]. However, unlike [RFC8032], the protocol for producing signatures in this draft is not deterministic, so as to ensure protection against a key-recovery attack that is possible when even only one signer participant is malicious. "RSA Blind Signatures", Frank Denis, Frederic Jacobs, Christopher Wood, 2022-11-21, This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments [Chaum83]. It extends RSA-PSS encoding specified in [RFC8017] to enable blind signature support. 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/chris-wood/draft-wood-cfrg-blind-signatures. "Deterministic Nonce-less Hybrid Public Key Encryption", Dan Harkins, 2022-08-09, 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. "Verifiable Distributed Aggregation Functions", Richard Barnes, Christopher Patton, Phillipp Schoppmann, 2022-08-24, 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 input that would result in an incorrect aggregate result. "Key Blinding for Signature Schemes", Frank Denis, Edward Eaton, Tancrede Lepoint, Christopher Wood, 2022-08-02, 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, Fabio Scotoni, Samuel Lucas, 2022-08-05, This document describes AEGIS-128L and AEGIS-256, two AES-based authenticated encryption algorithms designed for high-performance applications. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-aegis-aead. "Deterministic ECDSA and EdDSA Signatures with Additional Randomness", John Mattsson, Erik Thormarker, Sini Ruohomaa, 2022-08-08, Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security do not depend on a source of high-quality randomness. Recent research has however found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their determinism. One countermeasure to such attacks is to re-add randomness to the otherwise deterministic calculation of the per-message secret number. This document updates RFC 6979 and RFC 8032 to recommend constructions with additional randomness for 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, 2022-10-23, BBS is a digital signature scheme categorized as a form of short group signature that supports several unique properties. Notably, the scheme supports signing multiple messages whilst producing a single output digital signature. Through this capability, the possessor of a signature is able to generate proofs that selectively disclose subsets of the originally signed set of messages, whilst preserving the verifiable authenticity and integrity of the messages. Furthermore, these proofs are said to be zero-knowledge in nature as they do not reveal the underlying signature; instead, what they reveal is a proof of knowledge of the undisclosed signature. "Properties of AEAD algorithms", Andrey Bozhko, 2022-11-24, Authenticated Encryption with Associated Data (AEAD) algorithms provide confidentiality and integrity of data. The extensive use of AEAD algorithms in various high-level applications has caused the need for AEAD algorithms with additional properties and motivated research in the area. This document gives definitions for the most common of those properties intending to improve consistency in the field. Constrained RESTful Environments (core) --------------------------------------- "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2022-11-07, The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. "YANG Schema Item iDentifier (YANG SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, Carsten Bormann, Michael Richardson, 2022-07-26, 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 (-19) adds in draft text about objectives, // parties, and roles. This attempts to record discussions at side // meetings before, at, and after IETF 113. "Group OSCORE - Secure Group Communication for CoAP", Marco Tiloca, Goeran Selander, Francesca Palombini, John Mattsson, Jiye Park, 2022-10-24, This document defines 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 approach 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. "Constrained Resource Identifiers", Carsten Bormann, Henk Birkholz, 2022-09-07, The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes 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. The present revision -10 of this draft contains an experimental addition that allows representing user information (https://alice@chains.example) in the URI authority component. This feature lacks test vectors and implementation experience at the time of writing and requires discussion. "Group Communication for the Constrained Application Protocol (CoAP)", Esko Dijk, Chonggang Wang, Marco Tiloca, 2022-07-11, 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 RFC 7390, while it updates RFC 7252 and RFC 7641. "Profiling EDHOC for CoAP and OSCORE", Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander, 2022-11-23, The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document further profiles 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 subsequent 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, 2022-10-24, The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. "Conditional Attributes for Constrained RESTful Environments", Michael Koster, Alan Soloway, Bill Silverajan, 2022-10-24, This specification defines Conditional Notification and Control Attributes that work with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/conditional-attributes/ "Key Update for OSCORE (KUDOS)", Rikard Hoeglund, Marco Tiloca, 2022-10-24, 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 must follow these key usage limits and what steps they must take to preserve the security of their communications. Also, it specifies Key Update for OSCORE (KUDOS), a lightweight procedure that two peers can use to update their keying material and establish a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option. Finally, this document specifies a method that two peers can use to update their OSCORE identifiers, as a stand-alone procedure or embedded in a KUDOS execution. Thus, this document updates RFC 8613. "Attacks on the Constrained Application Protocol (CoAP)", John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess, 2022-11-10, Being able to securely read information from sensors, to securely control actuators, and to not enable distributed denial-of-service attacks are essential in a world of connected and networking things interacting with the physical world. Using a security protocol such as DTLS, TLS, or OSCORE to protect CoAP is a requirement for secure operation and protects against many attacks. This document summarizes a number of known attacks on CoAP deployments and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. Several of the discussed attacks can be mitigated with the solutions in RFC 9175. "CoAP Protocol Indication", Christian Amsuess, 2022-07-11, 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, 2022-10-24, 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 Attribute Registry", Carsten Bormann, 2022-11-23, The Constrained RESTful Environments (CoRE) specifications apply Web technologies to constrained environments. One important such technology is Web Linking [RFC8288], which CoRE uses as the basis for a number of discovery protocols, such as the Link Format [RFC6690] in CoAP's Resource Discovery Protocol (Section 7 of [RFC7252]) and the Resource Directory [RFC9176]. Web Links can have Target Attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of [RFC8288]). This short note introduces an IANA registry for coordinating names of Target Attributes when used in Constrained RESTful Environments. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Jim Schaad, 2022-10-13, The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. "CBOR Object Signing and Encryption (COSE): Countersignatures", Jim Schaad, Russ Housley, 2022-09-20, Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. "CBOR Encoded X.509 Certificates (C509 Certificates)", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2022-07-10, 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%. 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 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, Russ Housley, Brendan Moran, 2022-07-11, 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) encryption function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms. "CBOR Web Token (CWT) Claims in COSE Headers", Tobias Looker, Michael Jones, 2022-11-08, 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. "Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE", Tobias Looker, Michael Jones, 2022-10-24, 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. "JOSE and COSE Encoding for Post-Quantum Signatures", Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans, 2022-10-20, This document describes JSON and CBOR serializations for several Post-Quantum Cryptography (PQC) based suites including CRYSTALS Dilithium, Falcon, and SPHINCS+. This document does not define any new cryptography, only seralizations of existing cryptographic systems. This document registers key types for JOSE and COSE, specifically LWE, NTRU, and HASH. Key types in this document are specified by the cryptographic algorithm family in use by a particular algorithm as discussed in RFC7517. This document registers signature algorithms types for JOSE and COSE, specifically CRYDI3 and others as required for use of various post- quantum signature schemes. "CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC", Russ Housley, Hannes Tschofenig, 2022-11-08, The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 8152 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as Content Encryption algorithms with COSE. DANE Authentication for Network Clients Everywhere (dance) ---------------------------------------------------------- "TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor Dukhovni, Ash Wilson, 2022-11-08, 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, Ash Wilson, 2022-11-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, 2022-07-28, 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, 2022-10-04, 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 MPLS Data Plane", Greg Mirsky, Mach Chen, Balazs Varga, 2022-12-01, This document defines format and use principles of the Deterministic Network (DetNet) service Associated Channel (ACH) over a DetNet network with the MPLS data plane. The DetNet service ACH can be used to carry test packets of active Operations, Administration, and Maintenance protocols that are used to detect DetNet failures and measure performance metrics. "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane", Greg Mirsky, Mach Chen, David Black, 2022-08-22, This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. "Deterministic Networking (DetNet) Controller Plane Framework", Andrew Malis, Xuesong Geng, Mach Chen, Fengwei Qin, Balazs Varga, 2022-06-28, 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. "Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)", Greg Mirsky, Fabrice Theoleyre, Georgios Papadopoulos, Carlos Bernardos, Balazs Varga, Janos Farkas, 2022-10-06, Deterministic Networking (DetNet), as defined in RFC 8655, is aimed to provide a bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. "Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP", Balazs Varga, Janos Farkas, Andrew Malis, 2022-11-06, 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 [RFC8939] and the mechanisms defined in [RFC9025]. "Deterministic Networking (DetNet): Packet Ordering Function", Balazs Varga, Janos Farkas, Stephan Kehrer, Tobias Heer, 2022-11-06, Replication and Elimination functions of DetNet [RFC8655] may result in out-of-order packets, which may not be 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. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2022-08-03, In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Todd Herr, John Levine, 2022-11-09, 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, 2022-08-21, 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, 2022-10-20, 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) ------------------------------------- "Segment Routing IPv6 for Mobile User Plane", Satoru Matsushima, Clarence Filsfils, Miya Kohno, Pablo Camarillo, Dan Voyer, Charles Perkins, 2022-11-22, This document specifies the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing, and SLA control for various applications. "Mobility aware Transport Network Slicing for 5G", Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley, 2022-10-19, Slices in a 5G system should be identified and mapped to the corresponding transport network underlay segments to provide the capabilities requested by the 5G customer. One set of slices in a 5G system correspond to resources and connectivity to carry signaling and data plane packets across a distributed infrastructure that make up the 5G system, for example, distributed entities of a radio network (gNB). Another set of 5G slices represent resource and connectivity capabilities offered by the 5G system to its end users (UE) for the lifetime of a session including UE mobility. Both depend in part on multiple transport network slice segments with requirements that include bandwidth, latency, and criteria such as isolation, directionality, and disjoint routes. This document describes how a 5G slice is mapped to a slice in IP or Layer 2 transport network for both above cases, including scenarios where the 5G customer network is separated from the provider transport network by an intermediate network. Mobile slice criteria are mapped to the appropriate transport slice and capabilities offered in backhaul, mid-haul and fronthaul connectivity segments between radio side network functions and user plane function(gateway). Applicability of this framework and underlying transport networks, which can enable different slice properties are also discussed. This is based on mapping between mobile and transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4). Domain Name System Operations (dnsop) ------------------------------------- "The ALT Special Use Top Level Domain", Warren Kumari, Paul Hoffman, 2022-10-20, This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [ This document is being collaborated on in Github at . The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] "DNS Catalog Zones", Peter van Dijk, Libor Peltan, Ondrej Sury, Willem Toorop, Kees Monshouwer, Peter Thomassen, Aram Sargsyan, 2022-11-24, This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. "DNS Glue Requirements in Referral Responses", Mark Andrews, Shumon Huque, Paul Wouters, Duane Wessels, 2022-09-27, The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative Servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2022-10-11, This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. "Fragmentation Avoidance in DNS", Kazunori Fujiwara, Paul Vixie, 2022-08-21, EDNS0 enables a DNS server to send large responses using UDP and is widely deployed. Large DNS/UDP responses are fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document proposes to avoid IP fragmentation in DNS. "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Dmitry Belyavsky, Vasily Dolmatov, Boris Makarenko, 2022-11-30, 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). This document obsoletes RFC 5933 and updates RFC 8624. "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Ralph Dolmans, 2022-09-06, 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. Resolvers should also periodically revalidate the child delegation by re-quering the parent zone at the expiration of the TTL of the parent side NS RRset. "DNS Terminology", Paul Hoffman, Kazunori Fujiwara, 2022-07-27, 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 sometimes 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 obsoletes RFC 8499 and updates RFC 2308. "DNS Error Reporting", Roy Arends, Matt Larson, 2022-10-24, DNS Error Reporting is a lightweight error reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate, that a Domain Owner or DNS Hosting organization can use to improve domain hosting. The reports are based on Extended DNS Errors [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 recursive resolver to automatically signal an error to an agent specified by the authoritative server. DNS Error Reporting uses the DNS to report errors. "Using Service Bindings with DANE", Benjamin Schwartz, Robert Evans, 2022-06-22, Service Binding records introduce a new form of name indirection in DNS. This document specifies DNS-Based Authentication of Named Entities (DANE) interaction with Service Bindings to secure endpoints including use of ports and transports discovered via Service Parameters. 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/bemasc/svcb-dane. "DNS Security Extensions (DNSSEC)", Paul Hoffman, 2022-10-24, This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. "The "ZONEVERSION" EDNS option for the version token of a RR's zone", Hugo Salgado, Mauricio Ereche, 2022-09-13, The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with a token field representing the version of the zone which contains the answered Resource Record, such as the SOA serial field in zones when this number corresponds to the zone version. This "ZONEVERSION" data allows to debug and diagnose problems by helping to recognize the data source of an answer in an atomic single query, by associating the response with a respective zone version. "Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator", Peter Thomassen, Nils Wisiol, 2022-08-17, 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" ([RFC8078]). This document deprecates the DS enrollment methods described in Section 3 of [RFC8078] in favor of Section 3 of this document. [ 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. ] "Negative Caching of DNS Resolution Failures", Duane Wessels, William Carroll, Matthew Thomas, 2022-09-12, In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type. RFC 2308 specifies requirements for DNS negative caching. There, caching of type (1) and (2) responses is mandatory and caching of type (3) responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures. "Survey of Domain Verification Techniques using DNS", Shivan Sahib, Shumon Huque, Paul Wouters, 2022-07-28, Many services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS) [RFC1034] [RFC1035]. This verification is often done by requesting a specific DNS record to be visible in the domain. This document surveys various techniques in wide use today, the pros and cons of each, and proposes some practices to avoid known problems. Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "Service Registration Protocol for DNS-Based Service Discovery", Ted Lemon, Stuart Cheshire, 2022-10-12, 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 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. "An EDNS(0) option to negotiate Leases on DNS Updates", Stuart Cheshire, Ted Lemon, 2022-10-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, 2022-07-11, An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNSSD Service Registration Protocol (SRP), using multicast DNS. This allows legacy clients to discover services registered with SRP using multicast DNS. DDoS Open Threat Signaling (dots) --------------------------------- "Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", Yuhei Hayashi, chenmeiling, Li Su, 2022-10-23, DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission", Mohamed Boucadair, Jon Shallow, 2022-10-06, This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 CoAP options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission (especially, during DDoS attacks). Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132. DNS PRIVate Exchange (dprive) ----------------------------- "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS", Daniel Gillmor, Joey Salazar, Paul Hoffman, 2022-09-27, This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The steps in this document can be defeated by an active attacker, but should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. With wider easy deployment of the underlying transport on an opportunistic basis, we hope to facilitate the future specification of stronger cryptographic protections against more powerful attacks. Drone Remote ID Protocol (drip) ------------------------------- "Drone Remote Identification Protocol (DRIP) Architecture", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Shuai Zhao, Andrei Gurtov, 2022-08-16, This document describes an architecture for protocols and services to support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus UAS RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document (RFC9153). "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2022-12-02, This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). This document updates RFC7401 and RFC7343. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, e.g., DNS, RDAP) discovery for 3rd-party identifier endorsement. "DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-10-14, This document describes how to add trust into the Broadcast Remote ID (RID) specification discussed in the DRIP Architecture; first trust in the RID ownership and second in the source of the RID messages. It defines message types and associated formats (sent within the Authentication Message) that can be used to authenticate past messages sent by an unmanned aircraft (UA) and provide proof of UA trustworthiness even in the absence of Internet connectivity at the receiving node. "DRIP Entity Tag (DET) Identity Management Architecture", Adam Wiethuechter, Jim Reid, 2022-12-05, 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 the existing DNS structure and methods by using FQDNs. A general overview of the interfaces required between involved components is described in this document with supporting documents giving technical specifications. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "DTN Management Architecture", Edward Birrane, Sarah Heiner, Emery Annis, 2022-10-24, 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 can support asynchronous transport, autonomous local control, and require a very small footprint so as to deploy on resource 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 (BPv7). Operating using BPv7 require that the architecture not presume any synchronized transport behavior. This means that the DTNMA cannot operate as a query-response system across the network. This allows implementations compliant with the DTNMA to operate in extremely challenging conditions, such as over uni-directional links and other places where BPv7 is the preferred transport. "Update to the ipn URI scheme", Rick Taylor, Edward Birrane, 2022-11-07, The 'ipn' URI scheme was first defined in [RFC6260] as a format for endpoint identifiers with the Delay Tolerant Networking Bundle Protocol version 6 (BPv6) [RFC5050], when using Compressed Bundle Header Encoding (CBHE). [RFC7116] requested IANA registries to control the allocation of the numeric identifiers used with the 'ipn' URI scheme. The Bundle Protocol version 7 (BPv7) specification [RFC9171] repeats the definition of the 'ipn' URI scheme, for use with BPv7, reusing the format from [RFC6260]. Because the specification of the 'ipn' URI scheme has been split over several documents, referencing different versions of the Bundle Protocol, some confusion has occurred amongst readers and implementers. This document pulls together the information contained in those previous documents and asserts the specification of the 'ipn' URI scheme for use with BPv7, acting as an update to those previous documents. A criticism of the existing 'ipn' URI scheme node number allocation strategy as defined in [RFC7116] is that sub-ranges of a single number space are assigned for the use by individual organisations. This allocation strategy results in inefficient encoding of URIs with BPv7. This document extends the format of the 'ipn' URI scheme to include Numbering Authorities, allowing for a more flexible sub- allocation strategy, resulting in a more efficient encoding with BPv7. "Bundle Protocol Version 7 Administrative Record Types Registry", Brian Sipos, 2022-11-07, This document clarifies that a Bundle Protocol Version 7 agent is intended to use an IANA sub-registry for Administrative Record types. It also makes a code point reservation for private or experimental use. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "A LoST extension to return complete and similar location info", Brian Rosen, Roger Marshall, Jeff Martin, 2022-03-04, This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a . This extension supports two use cases: First, when the input location is valid but lacks some Civic Address elements, the LoST server can provide a completed form. Second, when the input location is invalid, the LoST server can identify one or more feasible ("similar") locations. This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222 or another profile whose definition provides instructions concerning its use with this extension. "Validation of Locations Around a Planned Change", Brian Rosen, 2022-11-07, This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoSR server ti notify a client of planned changes to the data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. This extension adds an element to the request: a date that allows the LoST client to request that the server perform validation as of the date specified. It adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. It also adds a separate interface to the LoST server that allows a client to poll for planned changes. Additionally, this document provides a conventional XML schema for LoST, as a backwards compatible alternative to the RelaxNG schema in RFC5222. "Emergency Registries", Brian Rosen, Brandon Abley, 2022-07-26, Multiple emergency services standards organizations are developing standards based on IETF emergency call standards and other IETF protocols. There is a desire among these organizations to use common registries not tied to a particular country or national Standards Development Organization (SDO), in the long term pursuit of a single worldwide standard. This document asks IANA to create a set of registries and provides processes for expanding the set and populating them. NomCom Eligibility Update (elegy) --------------------------------- "Nominating Committee Eligibility", Martin Duke, 2022-12-01, The IETF Nominating Committee (NomCom) appoints candidates to most IETF leadership committee. RFC8713 provides criteria for membership on NomCom that attempt to ensure that NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in- person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC8713 by building a new set of eligibility criteria from first principles, with consideration for the increased salience of remote attendance. Revision of core Email specifications (emailcore) ------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 2022-12-05, 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. "Applicability Statement for IETF Core Email Protocols", John Klensin, Kenneth Murchison, Ekow Sam, 2022-11-07, 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, 2022-10-04, 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, Vesa Torvinen, John Mattsson, 2022-10-23, Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication method, with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. "TLS-based EAP types and TLS 1.3", Alan DeKok, 2022-09-27, EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP- TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific EAP methods. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed. "Bootstrapped TLS Authentication", Owen Friel, Dan Harkins, 2022-10-24, 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. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "Sieve Email Filtering: Snooze Extension", Kenneth Murchison, Ricardo Signes, Neil Jenkins, 2022-09-06, This document describes the "snooze" extension to the Sieve email filtering language. The "snooze" extension gives Sieve the ability to postpone the delivery of an incoming email message into a target mailbox until a later point in time. "IANA registry for Sieve actions", Alexey Melnikov, Kenneth Murchison, 2022-08-15, This document creates a registry of Sieve (RFC 5228) actions in order to help developers and Sieve extension writers track interactions between different extensions. "IMAP Paged SEARCH & FETCH Extension", Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Luis Alves, 2022-12-05, The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to limit the number of search results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051. "Sieve Email Filtering: Extension for Processing iMIP Messages", Kenneth Murchison, Ricardo Signes, Matthew Horsfall, 2022-07-11, This document describes the "processimip" extension to the Sieve email filtering language. The "processimip" extension gives Sieve the ability to process messages using the iCalendar Message-Based Interoperability Protocol (iMIP). Open Issues "IMAP MESSAGELIMIT Extension", Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Luis Alves, 2022-11-11, 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 command. This helps servers to control resource usage when performing various IMAP operations. Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- "Grant Negotiation and Authorization Protocol", Justin Richer, Fabien Imbault, 2022-11-29, 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, Aaron Parecki, Fabien Imbault, 2022-07-11, 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 communicate 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, 2022-10-24, 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. "TLV support for BMP Route Monitoring and Peer Down Messages", Paolo Lucente, Yunan Gu, 2022-11-08, 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. "Support for Enterprise-specific TLVs in the BGP Monitoring Protocol", Paolo Lucente, Yunan Gu, 2022-11-08, 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, 2022-11-21, 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, 2022-11-25, This document proposes a YANG module for BMP (BGP Monitoring Protocol) configuration and monitoring. A complementary RPC triggers a refresh of the session of a BMP station. "A well-known BGP community to denote prefixes used for Anycast", Maximilian Wilhelm, Fredy Kuenzler, 2022-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. Home Networking (homenet) ------------------------- "Simple Provisioning of Public Names for Residential Networks", Daniel Migault, Ralf Weber, Michael Richardson, Ray Hunter, 2022-12-05, Home network owners may have devices or services hosted on this home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which makes this access much simpler. To enable this access, the names and IP addresses of these devices and services needs to be made available in the public DNS. The names and IP address of the home network are present in the Public Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs an outsourced infrastructure to publish the zone on the behalf of the home owner. This document describes how an this Home Naming Authority instructs the outsourced infrastructure. "DHCPv6 Options for Home Network Naming Authority", Daniel Migault, Ralf Weber, Tomek Mrugalski, 2022-10-31, This document defines DHCPv6 options so a Homenet Naming Authority (HNA) can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Guidelines for Human Rights Protocol and Architecture Considerations", Gurshabad Grover, Niels ten Oever, 2022-11-10, 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 (for example see: https://gitlab.com/hr-rt/documents). 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. "Internet Protocols and the Human Rights to Freedom of Association and Assembly", Niels ten Oever, Stephane Couture, Mallory Knodel, 2022-11-24, This document explores whether the relationship between the Internet architecture and the ability of people to exercise their rights to peaceful assembly and association online. It does so by asking the question: what are the protocol development considerations for freedom of assembly and association? The Internet increasingly mediates our lives, our relationships, and our ability to exercise our human rights. As a global assemblage, the Internet provides a public space, yet it is predominantly built on private infrastructure. Since Internet protocols and architecture play a central role in the management, development, and use of the Internet, we analyze the relation between protocols, architecture, and the rights to assemble and associate to mitigate infringements on those rights. This document concludes that the way in which infrastructure is designed and implemented impacts people's ability to exercise their freedom of assembly and association. It is therefore recommended that the potential impacts of Internet technologies should be assessed, reflecting recommendations of various UN bodies and international norms. Finally, the document considers both the limitations on changing association and impact of "forced association" in the context of online platforms. Building Blocks for HTTP APIs (httpapi) --------------------------------------- "RateLimit Fields for HTTP", Roberto Polli, Alex Ruiz, 2022-07-06, This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy fields for HTTP, thus allowing servers to publish current service limits and clients to shape their request policy and avoid being throttled out. "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal, 2022-09-05, This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content and/or fields to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RF7807. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-httpapi/rfc7807bis. "The Idempotency-Key HTTP Header Field", Jayadeba Jena, Sanjay Dalal, 2022-11-09, 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. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Building Blocks for HTTP APIs Working Group mailing list (httpapi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/httpapi/. Source for this draft and an issue tracker can be found at https://github.com/mnot/idempotency. "REST API Media Types", Roberto Polli, 2022-09-07, This document registers the following media types used in APIs on the IANA Media Types registry: application/schema+json, application/ schema-instance+json, application/openapi+json, and application/ openapi+yaml. "YAML Media Type", Roberto Polli, Erik Wilde, Eemeli Aro, 2022-11-23, This document registers the application/yaml media type and the +yaml structured syntax suffix on the IANA Media Types registry. HTTP (httpbis) -------------- "Cookies: HTTP State Management Mechanism", Steven Bingler, Mike West, John Wilander, 2022-11-07, 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. "Digest Fields", Roberto Polli, Lucas Pardue, 2022-06-19, This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny, 2022-11-21, This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer, and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. "The HTTP QUERY Method", Julian Reschke, Ashok Malhotra, James Snell, 2022-07-04, This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. "Client-Cert HTTP Header Field", Brian Campbell, Mike Bishop, 2022-12-02, This document describes HTTP extension header fields that allow a TLS terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. "Retrofit Structured Fields for HTTP", Mark Nottingham, 2022-12-04, This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). To accommodate some additional fields whose syntax is not compatible, it also defines mappings of their semantics into new Structured Fields. It does not specify how to negotiate their use. "The ORIGIN Extension in HTTP/3", Mike Bishop, 2022-11-29, The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but needs to be separately registered. This document describes the ORIGIN frame for HTTP/3. "tus - Resumable Uploads Protocol", Marius Kleidl, Guoye Zhang, Lucas Pardue, 2022-09-05, 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, 2022-11-09, 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. 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, 2022-11-07, This document describes an information model and the corresponding YANG data model for the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. The information model defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. This information model is based on the "Event- Condition-Action" (ECA) policy model defined by a capability information model for I2NSF, and the YANG data model is defined for enabling 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, 2022-11-08, This document defines an information model and 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 these information and data models 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) --------------------------------- "Maintaining Robust Protocols", Martin Thomson, David Schinazi, 2022-12-06, The main goal of the networking standards process is to enable the long term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. "Considerations on Application - Network Collaboration Using Path Signals", Jari Arkko, Ted Hardie, Tommy Pauly, Mirja Kuehlewind, 2022-10-19, This document discusses principles for designing mechanisms that use or provide path signals, and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements, and points out that visible information will be used whether it is intended as a signal or not. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. Information-Centric Networking (icnrg) -------------------------------------- "File-Like ICN Collections (FLIC)", Christian Tschudin, Christopher Wood, Marc Mosko, David Oran, 2022-10-24, 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. "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Hitoshi Asaeda, Atsushi Ooka, Xun Shao, 2022-10-05, This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF and is not issued by the IETF and is not an IETF standard. This is an experimental protocol and the specification may change in the future. "ICN Ping Protocol Specification", Spyridon Mastorakis, David Oran, Jim Gibson, Ilya Moiseenko, Ralph Droms, 2022-10-16, This document presents the design of an ICN Ping protocol. It includes the operations of both the client and the forwarder. This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF. "ICN Traceroute Protocol Specification", Spyridon Mastorakis, David Oran, Ilya Moiseenko, Jim Gibson, Ralph Droms, 2022-10-16, This document presents the design of an ICN Traceroute protocol. This includes the operation of both the client and the forwarder. This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF. "Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic", Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch, 2022-10-07, CCNx utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding such as that specified in [RFC5497] and [IEEE.754.2019]. This document updates _CCNx messages in TLV Format_ [RFC8609] to specify this alternative encoding. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). "Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2022-10-13, Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management. This specification derives directly from the design published in _Path Switching in Content Centric and Named Data Networks_ (4th ACM Conference on Information-Centric Networking - ICN'17) and therefore does not recapitulate the design motivations, implementation details, or evaluation of the scheme. Some technical details are different however, and where there are differences, the design documented here is to be considered definitive. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). Inter-Domain Routing (idr) -------------------------- "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, 2022-08-22, This document describes a mechanism to collect the Traffic Engineering Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang, 2022-10-09, This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. "BGP Community Container Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Bruno Decraene, Shane Amante, Paul Jakma, 2022-07-11, Route tagging plays an important role in external BGP relations, communicating various routing policies between peers. It is also a very common best practice for operators to propagate various additional route information between internal peers. The most common tool used today to attach various information about routes is through the use of BGP communities. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify and advertise an operator's parameters for execution It also provides an extensible platform for any future community encoding requirements. "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas, 2022-10-13, This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2022-07-10, This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. "BGP Flow Specification Filter for MPLS Label", Lucy Yong, Susan Hares, liangqiandeng, Jianjie You, 2022-10-20, This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. "Carrying Label Information for BGP FlowSpec", liangqiandeng, Susan Hares, Jianjie You, Robert Raszuk, Dan Ma, 2022-10-20, This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. "Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro, Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2022-10-12, [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2022-11-24, This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. 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. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain, Steven Lin, 2022-07-27, This document introduces a BGP SAFI with two NLRIs to advertise a candidate path of a Segment Routing (SR) Policy. An 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 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 Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, Daniel Bernier, Bruno Decraene, 2022-11-06, Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by various protocols such as BGP, IS-IS and OSPFv3. This document defines extensions to BGP Link-state (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data-plane defined in a separate document. "Flexible Algorithm Advertisement using BGP Link-State", Ketan Talaulikar, Peter Psenak, Shawn Zandi, Gaurav Dawra, 2022-08-24, Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. "Deprecation of AS_SET in BGP", Warren Kumari, Kotikalapudi Sriram, Lilia Hannachi, Jeffrey Haas, 2022-10-23, BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET in the Border Gateway Protocol. This document advances this recommendation to a standards requirement in BGP; it proscribes the use of the AS_SET type of path segments 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 route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document (if approved) updates RFC 4271 and RFC 5065, and obsoletes RFC 6472. "Support for Long-lived BGP Graceful Restart", Jim Uttaro, Enke Chen, Bruno Decraene, John Scudder, 2022-12-06, In this document, we introduce a new BGP capability termed "Long- lived Graceful Restart Capability" so that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (RFC 4724). A well-known BGP community "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community, "NO_LLGR", is introduced to mark routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least-preferred, and their advertisements be limited to BGP speakers that have advertised the new capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is. We update RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between PE and CE. "Distribution of Link-State and Traffic Engineering Information Using BGP", Ketan Talaulikar, 2022-11-18, In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC9029 by incorporating the updates that it made to RFC7752. "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu, 2022-11-06, 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 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, 2022-08-07, 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, Sujian Lu, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Haibo Wang, 2022-01-25, It is hard to adjust traffic and optimize traffic paths 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 and optimizes traffic paths automatically. This document describes BGP Extensions for Routing Policy Distribution (BGP RPD) to support this. "SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS", Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar, 2022-08-07, 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, 2022-10-23, 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. "BGP SR Policy Extensions to Enable IFIT", Fengwei Qin, Hang Yuan, Shunxing Yang, Tianran Zhou, Giuseppe Fioccola, 2022-10-24, 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 SDWAN Edge Discovery", Linda Dunbar, Susan Hares, Robert Raszuk, Kausik Majumdar, Gyan Mishra, 2022-08-13, The document describes the encoding of BGP UPDATE messages for the SDWAN edge node property discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SDWAN Controller that receives the BGP UPDATE from SDWAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SDWAN 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, 2022-10-03, This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. "BGP-LS Advertisement of Segment Routing Service Segments", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Francois Clad, Daniel Bernier, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Jim Guichard, Cheng Li, 2022-11-05, Service functions are deployed as, physical or virtualized elements along with network nodes or on servers in data centers. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. Service segments are SR segments that are associated with service functions. SR Policies are used for the setup of paths for steering of traffic through service functions using their service segments. BGP Link-State (BGP-LS) enables distribution of topology information from the network to a controller or an application in general so it can learn the network topology. This document specifies the extensions to BGP-LS for the advertisement of service functions along their associated service segments. The BGP-LS advertisement of service function information along with the network nodes that they are attached to, or associated with, enables controllers compute and setup service paths in the network. "BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks", Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li, 2022-09-12, Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a subset of the network topology and network resources allocated from the physical network. A VTN could be used as the underlay for one or a group of VPN+ services. When Segment Routing is used as the data plane of VTNs, each VTN can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the VTN. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In network scenarios where each VTN can be associated with a unique logical network topology, this document describes a mechanism to distribute the information of SR based VTNs using BGP-LS with Multi-Topology. "A BGP Cease Notification Subcode For Bidirectional Forwarding Detection (BFD)", Jeffrey Haas, 2022-10-13, The Bidirectional Forwarding Detection (BFD) protocol is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections faster than the native protocol timers. This document defines a Subcode for the BGP Cease NOTIFICATION message for when a BGP connection is being closed due to a BFD session going down. "BGP Flow Specification Version 2", Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke, 2022-10-21, 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, 2022-11-30, 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, 2022-07-06, 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. "BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities", Giuseppe Fioccola, Ran Pang, Subin Wang, Bruno Decraene, Shunwan Zhuang, Haibo Wang, 2022-09-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 extensions to Border Gateway Protocol (BGP) 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 would be useful for 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, 2022-08-28, 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, 2022-09-06, This document specifies a mechanism, referred to as "Intent Driven Service Mapping" to express association of overlay routes with underlay routes satisfying a certain SLA using BGP. The document describes a framework for classifying underlay routes into transport classes and mapping service routes to specific transport class. The "Transport class" construct maps to a desired SLA and can be used to realize the "Topology Slice" in 5G Network slicing architecture. This document specifies BGP protocol procedures that enable dissemination of such service mapping information that may span multiple cooperating administrative domains. These domains may be administetered by the same provider or by closely co-ordinating provider networks. A new BGP transport layer address family (SAFI 76) is defined for this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI encoding. This new address family is called "BGP Classful Transport", aka BGP CT. BGP CT makes it possible to advertise multiple tunnels to the same destination address, thus avoiding need of multiple loopbacks on the egress node. It carries transport prefixes across tunnel domain boundaries (e.g. in Inter-AS Option-C networks), which is parallel to BGP LU (SAFI 4) . It disseminates "Transport class" information for the transport prefixes across the participating domains, which is not possible with BGP LU. This makes the end-to-end network a "Transport Class" aware tunneled network. Though BGP CT family is used only in the option-C inter-AS neworks, the Service Mapping procedures described in this document apply in the same manner to Intra-AS service end points as well as Inter-AS option-A, option-B and option-C variations. "Traffic Steering using BGP FlowSpec with SRv6 Policy", Jiang Wenying, Yisong Liu, Shunwan Zhuang, Gyan Mishra, Shuanglong Chen, 2022-10-09, BGP Flow Specification (FlowSpec) [RFC8955] [RFC8956] has been proposed to distribute BGP 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 SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SRv6 Policy. "BGP Router Capabilities Attribute", Bruno Decraene, John Scudder, Wim Henderickx, Kireeti Kompella, satyamoh@cisco.com, Jim Uttaro, Bin Wen, 2022-10-10, 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 to be conveyed further. In particular, it may be useful to advertise forwarding plane features. This specification defines a new BGP transitive attribute to carry such capability information, the "Router Capabilities Attribute," or RCA. This specification also defines an RCA 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. "Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10.", Job Snijders, 2022-10-12, This document requests IANA to mark BGP OPEN Message Error subcodes 8, 9, and 10 as "deprecated". "BGP Extension for 5G Edge Service Metadata", Linda Dunbar, Kausik Majumdar, Haibo Wang, Gyan Mishra, 2022-12-02, This draft describes three new sub-TLVs for egress routers to advertise the Edge Service Metadata of the directly 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 specific User Equipment (UE). Internet Area Working Group (intarea) ------------------------------------- "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", Donald Eastlake, Joe Abley, Yizhou Li, 2022-09-18, Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters, 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. "Internet Protocol Number for SCHC", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2022-10-06, This document requests an Internet Protocol Number assignment for SCHC so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. IP Performance Measurement (ippm) --------------------------------- "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Greg Mirsky, Xiao Min, Wei Luo, 2022-07-10, 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. "In-situ OAM IPv6 Options", Shwetha Bhandari, Frank Brockners, 2022-10-11, 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 IPv6. "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2022-11-06, 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, 2022-07-07, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in user packets while the packets traverse a path between two points in the network. This document defines a YANG module for the IOAM function. "Simple TWAMP (STAMP) Extensions for Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Richard Foote, 2022-09-02, Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) extensions for SR networks, for both SR-MPLS and SRv6 forwarding planes by augmenting the optional extensions defined in RFC 8972. "Echo Request/Reply for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, Lei Bo, 2022-11-21, This document describes a generic format for use in echo request/ reply mechanisms, which can be used within an In situ Operations, Administration, and Maintenance (IOAM) domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC) and Bit Index Explicit Replication (BIER). "Integrity of In-situ OAM Data Fields", Frank Brockners, Shwetha Bhandari, Tal Mizrahi, Justin Iurman, 2022-11-24, 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. "In-situ OAM Deployment", Frank Brockners, Shwetha Bhandari, Daniel Bernier, Tal Mizrahi, 2022-10-12, 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. This document provides a framework for IOAM deployment and discusses best current practices. "Explicit Flow Measurements Techniques", Mauro Cociglio, Alexandre Ferrieux, Giuseppe Fioccola, Igor Lubashev, Fabio Bulgarella, Massimo Nilo, Isabelle Hamchaoui, Riccardo Sisto, 2022-10-13, This document describes protocol independent methods called Explicit Flow Measurement Techniques that employ few marking bits, inside the header of each packet, for loss and delay measurement. The endpoints, marking the traffic, signal these metrics to intermediate observers allowing them to measure connection performance, and to locate the network segment where impairments happen. Different alternatives are considered within this document. These signaling methods apply to all protocols but they are especially valuable when applied to protocols that encrypt transport header and do not allow traditional methods for delay and loss detection. "Test Protocol for One-way IP Capacity Measurement", Len Ciavattone, Alfred Morton, 2022-10-02, 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, Omer Shapira, Matt Mathis, 2022-07-11, 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 (fq_codel, cake, PIE) have solved the problem. Our networks remain unresponsive, not from a lack of technical solutions, but rather a lack of awareness of the problem and its solutions. We believe that creating a tool whose measurement matches people's everyday experience will create the necessary awareness, and result in a demand for products that solve the problem. This document specifies the "RPM 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 throughput (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, 2022-09-26, 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. "Alternate-Marking Method", Giuseppe Fioccola, Mauro Cociglio, Greg Mirsky, Tal Mizrahi, Tianran Zhou, 2022-07-25, This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. "Clustered Alternate-Marking Method", Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo Sisto, Tianran Zhou, 2022-09-26, This document generalizes and expands Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network that can result in a multipoint-to- multipoint network. The network clustering approach is presented and, for this reason, the technique here described is called "Clustered Alternate-Marking". This document obsoletes RFC 8889. "One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG", Zhenqiang Li, Tianran Zhou, Guo Jun, Greg Mirsky, Rakesh Gandhi, 2022-09-30, This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. "Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG", Zhenqiang Li, Tianran Zhou, Guo Jun, Greg Mirsky, Rakesh Gandhi, 2022-09-30, This document extends Simple Two-Way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance based traffic steering policy across the member links. "Precision Availability Metrics for SLO-Governed End-to-End Services", Greg Mirsky, Joel Halpern, Xiao Min, Alexander Clemm, John Strassner, Jerome Francois, 2022-12-06, 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 of SLOs. Specifically, PAM can be used by providers and/or users of the Network Slice service to assess whether the service is provided in compliance with its specified quality, i.e., in accordance with its defined SLOs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana Prasad, 2022-09-27, This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. "IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security", Christian Hopps, 2022-09-04, This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payloads. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. "Group Key Management using IKEv2", Valery Smyslov, Brian Weis, 2022-10-06, 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 require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. 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 one of transform types defined there. "Multiple Key Exchanges in IKEv2", C. Tjhai, M. Tomlinson, G. Bartlett, Scott Fluhrer, Daniel Van Geest, Oscar Garcia-Morchon, Valery Smyslov, 2022-12-01, This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so that the resulting shared key is resistant against quantum computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. Another possible application for this extension is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document utilizes the IKE_INTERMEDIATE exchange, by means of which multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is up (during rekeys or creating additional Child SAs). This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. "A YANG Data Model for IP Traffic Flow Security", Don Fedyk, Christian Hopps, 2022-09-22, This document describes a YANG module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. "Deprecation of IKEv1 and obsoleted algorithms", Paul Wouters, 2022-11-18, Internet Key Exchange version 1 (IKEv1) has been deprecated and its specification in RFC2407, RFC2408 and RFC2409 have been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document updates RFC 8221 and RFC 8247 and adds a Status column to the IANA IKEv2 Transform Type registries that shows the deprecation status. "Definitions of Managed Objects for IP Traffic Flow Security", Don Fedyk, Eric Kinzie, 2022-10-21, This document describes managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. "Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery Smyslov, 2022-09-12, This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ). "Announcing Supported Authentication Methods in IKEv2", Valery Smyslov, 2022-07-11, 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. IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Jaehoon Jeong, 2022-10-24, This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy). JSON Mail Access Protocol (jmap) -------------------------------- "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2022-12-04, This document specifies a data model for synchronizing calendar data with a server using JMAP. "JMAP for Quotas", Rene Cordier, 2022-11-30, This document specifies a data model for handling quotas on accounts with a server using JMAP. "JMAP for Sieve Scripts", Kenneth Murchison, 2022-11-16, This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). "JMAP for Tasks", Joris Baum, Hans-Joerg Happel, 2022-10-21, This document specifies a data model for synchronizing task data with a server using JMAP. "JMAP Sharing", Neil Jenkins, 2022-10-05, This document specifies a data model for sharing data between users using JMAP. "JMAP Blob management extension", Bron Gondwana, 2022-11-10, The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. "JMAP extension for S/MIME signing and encryption", Alexey Melnikov, 2022-07-11, This document specifies an extension to JMAP for sending S/MIME signed and S/MIME encrypted messages. "JMAP for Contacts", Neil Jenkins, 2022-10-17, This document specifies a data model for synchronising contacts data with a server using JMAP. JSON Path (jsonpath) -------------------- "JSONPath: Query expressions for JSON", Stefan Gossner, Glyn Normington, Carsten Bormann, 2022-11-21, JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from a JSON value. "I-Regexp: An Interoperable Regexp Format", Carsten Bormann, Tim Bray, 2022-10-17, This document specifies I-Regexp, a flavor of regular expressions that is limited in scope with the goal of interoperation across many different regular-expression libraries. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Margaret Cullen, Simon Josefsson, 2021-05-10, Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks that facilitate an extensible authentication model, among other things. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. "SPAKE Pre-Authentication", Nathaniel McCallum, Simo Sorce, Robbie Harwood, Greg Hudson, 2022-06-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. Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John Mattsson, Francesca Palombini, 2022-11-28, 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, 2022-10-24, This document contains some example traces of Ephemeral Diffie- Hellman Over COSE (EDHOC). Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Certificate Management Protocol (CMP) Updates", Hendrik Brockhaus, David von Oheimb, John Gray, 2022-06-29, This document contains a set of updates to the syntax and transfer of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210, RFC 5912, and RFC 6712. The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments. CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signaling the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. "Lightweight Certificate Management Protocol (CMP) Profile", Hendrik Brockhaus, David von Oheimb, Steffen Fries, 2022-12-06, This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. "Header Protection for S/MIME", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2022-11-22, 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 to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. "Certificate Management Protocol (CMP) Algorithms", Hendrik Brockhaus, Hans Aschauer, Mike Ounsworth, John Gray, 2022-06-02, This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile from RFC 4210 Appendix D.2. "Guidance on End-to-End E-mail Security", Daniel Gillmor, 2022-11-22, 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 that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common failures. "General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates", Tadahiko Ito, Tomofumi Okubo, Sean Turner, 2022-09-29, RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines a general purpose document signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document Signing applications may require that the EKU extension be present and that a document signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document Signing application. "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", Stefan Santesson, Russ Housley, Trevor Freeman, Leonard Rosenthol, 2022-11-29, This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFC 3709 and RFC 6170. "Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray, 2022-10-24, 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 includes the updates on RFC 4210 specified by CMP Updates [RFCAAAA] Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoleted 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 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. "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray, 2022-08-11, This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates on RFC 6712 specified in CMP Updates [RFCAAAA] 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, 2022-09-30, 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. "X.509 Certificate Extension for 5G Network Function Types", Russ Housley, Sean Turner, John Mattsson, Daniel Migault, 2022-11-29, This document specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509v3 public key certificates as profiled in RFC 5280. "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber", Sean Turner, Panos Kampanakis, Jake Massimo, Bas Westerbaan, 2022-09-26, This document specifies algorithm identifiers and ASN.1 encoding format for the United States National Institute of Standards and Technology's Post Quantum Cryptography Key Encapsulation Mechanism algorithms. The algorithms covered are Kyber TBD1. The encoding for public key and private key is also provided. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. After NIST has standardized its first algorithms, this document will replace TBD, with the appropriate algorithms and parameters before proceeding to ratification. The algorithm Kyber TBD1 has been added as an example in this draft, to provide a more detailed illustration of the content - it by no means indicates its inclusion in the final version. 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 Dilithium", Jake Massimo, Panos Kampanakis, Sean Turner, Bas Westerbaan, 2022-09-29, Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using Dilithium quantum-resistant signatures in Internet X.509 certificates and certificate revocation lists. The conventions for the associated post-quantum 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, 2022-10-05, This document specifies additions and amendments to RFC 7292. 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 PBKDFs and allow for regulatory compliance. "Key Attestation Extension for Certificate Management Protocols", Carl Wallace, Sean Turner, 2022-10-17, Certification Authorities (CAs) issue certificates for public keys conveyed to the CA via a certificate management message or protocol. In some cases, a CA may wish to tailor certificate contents based on whether the corresponding private key is secured by hardware in non- exportable form. This document describes extensions that may be included in any of several widely used certificate management protocols to convey attestations about the private key to the CA to support this determination. "Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas Westerbaan, 2022-11-21, SPHINCS+ is a stateless hash-based signature scheme. This document specifies the conventions for using the SPHINCS+ stateless hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. "Use of KYBER in the Cryptographic Message Syntax (CMS)", Julien Prat, Mike Ounsworth, 2022-11-10, This document describes the conventions for using a Key Encapsulation Mechanism algorithm (KEM) within the Cryptographic Message Syntax (CMS). The CMS specifies the envelopped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The mechanism proposed here can rely on either post-quantum KEMs, hybrid KEMs or classical KEMs but this document specifies the use of Kyber. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino, 2022-08-29, 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, 2022-09-11, 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, 2022-07-24, 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, 2022-10-03, 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, 2022-07-10, 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, 2022-09-11, 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, 2022-09-11, 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. "Publish/Subscribe Functionality for LISP", Alberto Rodriguez-Natal, Vina Ermagan, Albert Cabellos-Aparicio, Sharon Barkai, Mohamed Boucadair, 2021-06-28, This document specifies an extension to the Request/Reply based LISP Control Plane to enable Publish/Subscribe (PubSub) operation. "LISP Control-Plane ECDSA Authentication and Authorization", Dino Farinacci, Erik Nordmark, 2022-09-11, 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. "Network-Hexagons:Geolocation Mobility Edge Network Based On H3 and LISP", Sharon Barkai, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Dino Farinacci, 2022-10-22, This document uses virtual layer3 routing and geospatial addressing based on a hierarchical grid in forming a Geolocation mobility-edge network. When vehicles with AI cameras detect objects of interest on the road, they use their GPS to calculate their high-resolution grid-tile position, they then use this tile to calculate the high-resolution tile of the detection. A low-resolution tile which contains the detection-tile identifies a network-addressable object. The object tile-ID is used as basis for IPv6 endpoint identifier(EID). Geospatial EIDs are queue-destination and channel-source of objects. Geolocation objects consolidate detections form all vehicles in a given area. Geolocation objects based on EID queues and channels are network portable via the Locator/ID Separation Protocol (LISP). "LISP Map Server Reliable Transport", Darrel Lewis, Balaji Venkatachalapathy, Marc Portoles-Comeras, Isidor Kouvelas, Chris Cassar, 2022-07-10, 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, 2022-09-06, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2022-11-24, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "Data Model for Static Context Header Compression (SCHC)", Ana Minaburo, Laurent Toutain, 2022-10-09, This document describes a YANG data model for the SCHC (Static Context Header Compression) compression and fragmentation rules. This document formalizes the description of the rules for better interoperability between SCHC instances either to exchange a set of rules or to modify some rules parameters. "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Sergio Aguilar, Laurent Toutain, Sandra Cespedes, Diego Torre, Julien Boite, 2022-12-05, The Static Context Header Compression and fragmentation (SCHC) specification (RFC8724) describes a generic framework for application header compression and fragmentation modes designed for Low Power Wide Area Network (LPWAN) technologies. The present document defines a profile of SCHC (RFC8724) over Sigfox LPWAN, and provides optimal parameter values and modes of operation. "Static Context Header Compression over Narrowband Internet of Things", Edgar Ramos, Ana Minaburo, 2022-11-06, This document describes Static Context Header Compression and Fragmentation (SCHC) specifications, RFC 8724 and RFC 8824, combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT). This document has two parts. One normative to specify the use of SCHC over NB-IoT. And one informational, which recommends some values if 3GPP wanted to use SCHC inside their architectures. "LPWAN Static Context Header Compression (SCHC) Architecture", Alexander Pelov, Pascal Thubert, Ana Minaburo, 2022-06-30, This document defines the LPWAN SCHC architecture. "SCHC Compound ACK", Juan Zuniga, Carles Gomez, Sergio Aguilar, Laurent Toutain, Sandra Cespedes, Diego Torre, 2022-12-05, The present document describes an extension to the SCHC (Static Context Header Compression and fragmentation) protocol RFC8724. It defines a SCHC Compound ACK message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK). Both message format and procedure are generic, so they can be used, for instance, by any of the four LWPAN technologies defined in RFC8376, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. Link State Routing (lsr) ------------------------ "YANG Data Model for OSPF Segment Routing", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2022-07-03, This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing. It also defines a module for management of Signaling Maximum SID Depth (MSD) Using OSPF. "YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2022-08-18, This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2022-10-17, IGP protocols historically compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. "IGP extension for PCEP security capability support in PCE discovery", Diego Lopez, Qin WU, Dhruv Dhody, Qiufang Ma, Daniel King, 2022-10-11, When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in the IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCE Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS), TCP Authentication Option (TCP-AO)) support capability. This document defines capability flag bits for the PCE-CAP-FLAGS sub- TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFC 5088 and RFC 5089 to allow advertisement of a Key ID or Key Chain Name Sub-TLV to support TCP-AO security capability. Further, this document updates RFC 8231 and RFC 8306. "Dynamic Flooding on Dense Graphs", Tony Li, Tony Przygienda, Peter Psenak, Les Ginsberg, Huaimo Chen, David Cooper, Luay Jalil, Srinath Dontula, Gyan Mishra, 2022-06-07, 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. "IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu, 2022-11-14, The Segment Routing (SR) architecture allows flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, 2022-07-09, 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 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, 2022-08-30, 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. "IS-IS Extended Hierarchy", Tony Li, Les Ginsberg, Paul Wells, 2022-06-28, The IS-IS routing protocol was originally defined with a two level hierarchical structure. This was adequate for the networks at the time. As we continue to expand the scale of our networks, it is apparent that additional hierarchy would be a welcome degree of flexibility in network design. This document defines IS-IS Levels 3 through 8. "OSPF BFD Strict-Mode", Ketan Talaulikar, Peter Psenak, Albert Fu, Rejesh Shetty, 2022-10-06, This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise the requirement for strict-mode BFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established. This document updates RFC2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to Two-Way state when operating in OSPF BFD strict-mode. "OSPF Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston, 2022-10-10, This document specifies the extensions to OSPF that enable a router to use link-local signaling to signal the metric that receiving OSPF neighbor(s) should use for a link to the signaling router. The signaling of this reverse metric, to be used on the link to the signaling router, allows a router to influence the amount of traffic flowing towards itself and in certain use cases enables routers to maintain symmetric metrics on both sides of a link between them. "OSPFv3 Extensions for SRv6", Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak, 2022-09-14, The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support Segment Routing over the IPv6 data plane (SRv6). "Flooding Topology Minimum Degree Algorithm", Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2022-07-05, 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. "IS-IS Flood Reflection", Tony Przygienda, Chris Bowers, Yiu Lee, Alankar Sharma, Russ White, 2022-12-05, This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which L1 areas provide transit forwarding for L2 using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 LSPDUs and are used in the L2 SPF computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than traditionally used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network. "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, 2022-10-03, 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. "Advertising Layer 2 Bundle Member Link Attributes in OSPF", Ketan Talaulikar, Peter Psenak, 2022-10-07, There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisment of these OSPF extensions via BGP Link State protocol and thereby updates RFC9085. "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan, 2022-09-28, This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", William Britto, Shraddha Hegde, Parag Kaneriya, Rejesh Shetty, Ron Bonica, Peter Psenak, 2022-10-21, An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee Lindem, Peter Psenak, Yingzhen Qu, 2022-11-28, 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, 2022-09-05, 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, and IS-IS Flexible Algorithm. "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network", Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li, 2022-07-10, Enhanced VPN (VPN+) aims to provide enhanced VPN service 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 consists of a subset of network resources allocated on network nodes and links in a customized topology of the physical network. A VTN could be used as the underlay to support one or a group of VPN+ services. In some network scenarios, each VTN can be associated with a unique logical network topology. This document describes a mechanism to build the SR based VTNs 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, 2022-07-09, 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, Rejesh Shetty, Bruno Decraene, Peter Psenak, Tony Li, 2022-07-08, Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provides 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, 2022-07-25, 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, 2022-09-25, This document defines a YANG data model that can be used to configure and manage OSPFv3 SRv6 as defined in I-D.ietf-lsr- ospfv3-srv6-extensions. "YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng, Qiufang Ma, 2022-09-25, This document defines a YANG data model that can be used to configure and manage IS-IS SRv6 [I-D.ietf-lsr-isis-srv6-extensions]. "IS-IS Fast Flooding", Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Chris Bowers, Gunter Van de Velde, Peter Psenak, Tony Przygienda, 2022-07-11, 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. "Update to OSPF Terminology", Mike Fox, Acee Lindem, Alvaro Retana, 2022-07-09, This document updates some OSPF terminology to be in line with inclusive language used in the industry. 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 updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243, RFC5614, and RFC5838. "IS-IS Application-Specific Link Attributes", Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx, John Drake, 2022-10-24, Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. "OSPF Application-Specific Link Attributes", Peter Psenak, Les Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake, 2022-10-24, Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. Light-Weight Implementation Guidance (lwig) ------------------------------------------- "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. "Minimal IP Encapsulating Security Payload (ESP)", Daniel Migault, Tobias Guggemos, 2022-09-23, This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard RFC4303 ESP. Such a minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of RFC 4303 ESP. In addition, this document also provides some considerations for implementing minimal ESP in a constrained environment which includes limiting the number of flash writes, handling frequent wakeup / sleep states, limiting wakeup time, and reducing the use of random generation. This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description. "Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez, 2022-06-29, 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. MAC Address Device Identification for Network and Application Services (madinas) -------------------------------------------------------------------------------- "Randomized and Changing MAC Address Use Cases", Jerome Henry, Yiu Lee, 2022-10-06, To limit the privacy and security issues created by the association between a device, its traffic, its location and its user, client vendors have started implementing MAC address rotation. When such rotation happens, some in-network states may break, which may affect network efficiency and the user experience. At the same time, devices may continue sending other stable identifiers, defeating the MAC rotation purposes. This document lists various network environments and a set of functional 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, and settings where other machine identifiers may help re- identify the user or recover the identity of the user, and locate the device and its associated user. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. "MAC address randomization", Juan Zuniga, Carlos Bernardos, Amelia Andersdotter, 2022-10-22, Internet privacy has become a major concern over the past few years. Users are becoming more aware that their online activity leaves a vast digital footprint, that communications are not always properly secured, and that their location and actions can be easily tracked. One of the main factors for the location tracking issue is the wide use of long-lasting identifiers, such as MAC addresses. There have been several initiatives at the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities, with the intention to inform the technical community about them, and help coordinate between present and future standardization activities. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng, David Wiggins, Lou Berger, Stan Ratliff, 2022-07-29, 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, David Wiggins, Lou Berger, 2022-07-29, 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. Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- "IP Proxying Support for HTTP", Tommy Pauly, David Schinazi, Alex Chernyakhovsky, Mirja Kuehlewind, Magnus Westerlund, 2022-09-27, This document describes a method of proxying IP packets over HTTP. This protocol is similar to CONNECT-UDP, but allows transmitting arbitrary IP packets, without being limited to just TCP like CONNECT or UDP like CONNECT-UDP. MBONE Deployment (mboned) ------------------------- "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2022-08-31, 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, 2022-08-11, This document discusses the requirements of on-path telemetry for multicast traffic using In-situ OAM. Applying In-situ OAM for multicast telemetry presents some unique challenges. 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 collecting redundant data. "Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang, Yisong Liu, Ying Cheng, Gyan Mishra, 2022-07-11, 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. Media Type Maintenance (mediaman) --------------------------------- "The 'haptics' Top-level Media Type", Yeshwant Muthusamy, Chris Ullrich, 2022-11-23, 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 application for a set of intended subtypes, which are representative of some existing subtypes already in use. "Media Types with Multiple Suffixes", Manu Sporny, Amy Guy, 2022-10-10, 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, 2022-11-01, The goal of this document is to identify best practices for defining new top-level media types. It updates RFC 6838, when approved. 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. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, Katriel Cohn-Gordon, 2022-07-11, Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. "The Messaging Layer Security (MLS) Architecture", Benjamin Beurdouche, Eric Rescorla, Emad Omara, Srinivas Inguva, Albert Kwon, Alan Duric, 2022-08-19, The Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol] specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and secure group messaging. The MLS protocol is meant to protect against eavesdropping, tampering, message forgery, and provide further properties such as Forward Secrecy (FS) and Post-Compromise Security (PCS) in the case of past or future device compromises. This document describes a general secure group messaging infrastructure and its security goals. 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 the MLS Protocol document and left to the application or the infrastructure architects to design. 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 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, 2022-11-25, 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, 2022-11-14, 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, we discuss those applications that run on devices having different form factors 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. We discuss the expected behavior of XR applications which can be used to manage the traffic. In addition, we discuss the service requirements of XR applications to be able to run on the network. 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, 2022-11-07, 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 MPLS LSP echo request that allows a BFD system request that the remote BFD peer transmits BFD control packets over the specified LSP. "Refresh-interval Independent FRR Facility Protection", Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella, 2022-06-19, 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. "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, 2022-10-13, 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 Using RFC 6374 for Segment Routing Networks with MPLS Data Plane", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Stefano Salsano, Mach Chen, 2022-08-23, Segment Routing (SR) leverages the source routing paradigm. RFC 6374 specifies protocol mechanisms to enable the 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. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR networks with MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for RFC 6374. "A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow, Siva Sivabalan, 2022-08-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 modifying 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. A Querier MUST wait a configured time (suggested wait of 60 seconds) before re-attempting a Withdraw request. No more than three Withdraw requests SHOULD be made. These restrictions are to prevent overloading the control plane of the actioning router. "Encapsulation For MPLS Performance Measurement with Alternate Marking Method", Weiqiang Cheng, Xiao Min, Tianran Zhou, Ximing Dong, Yoav Peleg, 2022-07-01, This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on live traffic. "Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms", Deepti Rathi, Shraddha Hegde, Kapil Arora, Zafar Ali, Nagendra Nainar, 2022-10-07, MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for SR as defined in RFC 8287 is very useful to precisely validate the control plane and data plane synchronization. There is a possibility that all intermediate or transit nodes may not have been upgraded to support these validation procedures. A simple mpls ping and traceroute mechanism comprises of ability to traverse any path without having to validate the control plane state. RFC 8029 supports this mechanism with Nil FEC. The procedures described in RFC 8029 are mostly applicable when the Nil FEC is used as intermediate FEC in the label stack. When all labels in label stack are represented using single Nil FEC, it poses some challenges. This document introduces new TLV as additional extension to exisiting Nil FEC and describes mpls ping and traceroute procedures using Nil FEC with this additional extensions to overcome these challenges. "PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks", Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar, 2022-06-13, Segment 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 ASes under the control of 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 facilitae LSP ping and traceroute in inter-AS/inter-domain SR-MPLS networks in an efficient manner with simple Operations, Administration, and Maintenance (OAM) protocol extension which uses dataplane forwarding alone for sending echo reply. "BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Greg Mirsky, Gyan Mishra, Donald Eastlake, 2022-08-18, 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. 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, 2022-10-24, 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 working groups participating in the MPLS Open Design Team. "Requirements for MPLS Network Actions", Matthew Bocci, Stewart Bryant, John Drake, 2022-10-13, This document specifies requirements for MPLS network actions which affect the forwarding or other processing of MPLS packets. These requirements are derived from a number of proposals for additions to the MPLS label stack to allow forwarding or other processing decisions to be made, either by a transit or terminating LSR (i.e. the LER). "mLDP Extensions for Multi-Topology Routing", IJsbrand Wijnands, Syed Raza, Mankamana Mishra, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko, 2022-07-26, 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 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 Multi-Point LSPs it can follow a particular topology and algorithm. "MPLS Network Actions Framework", Loa Andersson, Stewart Bryant, Matthew Bocci, Tony Li, 2022-10-21, 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 describes 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 Action Indicators and Ancillary Data". "A YANG Model for MPLS MSD", Yingzhen Qu, Acee Lindem, Stephane Litkowski, Jeff Tantsura, 2022-10-21, This document defines a YANG data module augmenting the IETF MPLS YANG model to provide support for MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, 2022-10-19, This document defines three YANG 1.1 modules: the first defines features and groupings common to both TLS clients and TLS servers, the second defines a grouping for a generic TLS client, and the third defines a grouping for a generic TLS server. 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 * FFFF --> 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: * 2022-10-19 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix B. Change Log "RESTCONF Client and Server Models", Kent Watsen, 2022-10-19, This document defines 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: * 2022-10-19 --> 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 Informative Reference in the Appendix. 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, 2022-10-19, This document defines three YANG 1.1 modules: the first defines features and groupings common to both SSH clients and SSH servers, the second defines a grouping for a generic SSH client, and the third defines a grouping for a generic SSH server. 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: * 2022-10-19 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix B. Change Log "NETCONF Client and Server Models", Kent Watsen, 2022-10-19, This document defines 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: * 2022-10-19 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "A YANG Data Model for a Keystore", Kent Watsen, 2022-10-19, This document defines 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, 2022-10-19, 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, 2022-10-19, This document defines 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, 2022-10-19, This document defines 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, 2022-11-04, This document defines a protocol for sending notifications 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, 2022-10-19, This document defines 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). 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 * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> 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: * 2022-10-19 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "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, 2022-07-08, This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. "UDP-based Transport for Configured Subscriptions", Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente, 2022-09-12, This document describes an UDP-based notification mechanism to collect data from networking devices. 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, 2022-11-06, 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. 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, Olof Hagsand, Hongwei Li, Per Andersson, 2022-07-24, 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, Olof Hagsand, Hongwei Li, Per Andersson, 2022-07-24, 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, 2022-07-24, 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. "NETCONF over TLS 1.3", Sean Turner, Russ Housley, 2022-10-24, RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document describes how to protect NETCONF messages with TLS 1.3. Network Modeling (netmod) ------------------------- "A YANG Data Model for Syslog Configuration", Joe Clarke, Mahesh Jethanandani, Clyde Wildes, Kiran Koushik, 2022-10-11, 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. "YANG Module Versioning Requirements", Joe Clarke, 2022-07-10, 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, 2022-12-05, 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, 2022-10-24, This document 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 an earliest revision filter to better represent inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. It provides a mechanism, via the revision-label YANG extension, to specify a revision identifier for YANG modules and submodules. 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, 2022-10-24, This document specifies a scheme and guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines an RFCAAAA-compliant revision-label-scheme for this YANG semantic versioning scheme. "Node Tags in YANG Modules", Qin WU, Benoit Claise, Peng Liu, Zongpeng Du, Mohamed Boucadair, 2022-10-13, This document defines a method to tag nodes that are associated with 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, 2022-11-29, This document updates NMDA to define a read-only conventional configuration datastore called "system" to hold system-defined configurations. To avoid clients' explicit copy/paste of referenced system-defined configuration into the target configuration datastore (e.g., ), a "resolve-system" parameter has been defined to allow the server acting as a "system client" to copy referenced system-defined nodes automatically. The solution enables clients manipulating the target configuration datastore (e.g., ) to overlay and reference nodes defined in , override values of configurations defined in , and configure descendant nodes of system-defined nodes. Network File System Version 4 (nfsv4) ------------------------------------- "RPC-over-RDMA Version 2 Protocol", Chuck Lever, David Noveck, 2022-06-28, This document specifies the second version of a transport protocol that conveys Remote Procedure Call (RPC) messages using Remote Direct Memory Access (RDMA). This version of the protocol is extensible. "Internationalization for the NFSv4 Protocols", David Noveck, 2022-09-25, 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 with NVMe", Christoph Hellwig, Chuck Lever, Sorin Faibish, David Black, 2022-10-22, This document explains how to use the Parallel Network File System (pNFS) SCSI Layout Type with transports using the NVMe or NVMe over Fabrics protocol. Network Management (nmrg) ------------------------- "Digital Twin Network: Concepts and Reference Architecture", Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed Boucadair, Christian Jacquenet, 2022-10-24, 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. Individual Submissions (none) ----------------------------- "Mapping Between MIME Types, Content-Types, and URIs", Donald Eastlake, 2022-11-28, Multipurpose Internet Mail Extension (MIME) Content-Type headers, the MIME types used therein, and Uniform Resource Identifiers (URIs) are being used, in different contexts, to label entities. A mapping is specified from each kind of label into the other. This makes it possible to express the meaning of almost any URI or Content-Type in the syntax of the other. "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2022-10-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, 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, 2022-09-17, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD)", Palanivelan Appanasamy, 2011-11-17, This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 2010-03-23, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen, 2022-08-23, 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. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2022-07-11, 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. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2022-07-11, 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. "OSPF Abnormal State Information", Huaimo Chen, 2022-08-15, This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 2022-09-17, 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, 2022-09-17, 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. "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen, 2022-07-11, 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, 2022-07-11, 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, 2022-07-11, 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. "A SAVI Solution for WLAN", Jun Bi, Jianping Wu, Tao Lin, You Wang, Lin He, 2022-11-13, 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. "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, 2022-10-16, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 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. "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. "A Framework for Energy Aware Control Planes", Alvaro Retana, Russ White, Manuel Paul, 2022-08-22, Energy is a primary constraint in large-scale network design, particularly in cloud-scale data center fabrics. While compute and storage clearly consume the largest amounts of energy in large-scale networks, the optics and electronics used in transporting data also contribute to energy usage and heat generation. This document provides an overview of various areas of concern in the interaction between network performance and efforts at energy aware control planes, as a guide for those working on modifying current control planes or designing new ones to improve the energy efficiency of high density, highly complex, network deployments. "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. "Observations on the experience and nature of Large Interim Meetings", Joel Jaeggli, Jari Arkko, 2013-01-14, Planning, particpipation and conclusions from the experience of participating in the IETF LIM activity on september 29th 2012. "I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung Kwon, 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, 2022-06-13, 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, 2022-09-13, 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. "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Phillip Hallam-Baker, 2022-10-23, Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html. "QoS-level aware Transmission Protocol (QTP) for virtual networks", Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan, 2022-10-03, This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. "Remote APDU Call Secure (RACS)", Pascal Urien, 2022-10-04, 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, 2022-07-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, 2022-09-17, 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, 2022-07-11, 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. "An IP option for describing the traffic flow", Robert Chodorek, 2022-08-14, Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. The proposed IP option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes. "SAML Profile for the Metadata Query Protocol", Ian Young, 2022-07-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.18. "Just because it's an Internet-Draft doesn't mean anything... at all...", Warren Kumari, 2022-11-06, Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson, 2022-07-29, This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the OPSAWG 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/pcapng/pcapng. "Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)", Thomas Dreibholz, 2022-09-17, This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. "TCP SYN Extended Option Space Using an Out-of-Band Segment", Joseph Touch, Ted Faber, 2022-10-22, This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. "Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen Cheng, Peng Wang, Tong Duan, 2022-10-03, 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. "Declaring Kerberos Realm Names in DNS (_kerberos TXT)", Rick van Rein, 2022-11-08, This specification defines a method to determine Kerberos realm names for services that are known by their DNS name. Currently, such information can only be found in static mappings or through educated guesses. DNS can make this process more flexible, provided that DNSSEC is used to assure authenticity of resource records. "SMTP Service Extension for Client Identity", William Storey, 2022-11-24, 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, 2022-10-21, 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, Gyan Mishra, Siva Sivabalan, 2022-09-05, 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. "Quantum Relief with TLS and Kerberos", Rick van Rein, Tom Vrancken, 2022-10-21, This specification describes a mechanism to use Kerberos authentication within the TLS protocol. This gives users of TLS a strong alternative to classic PKI-based authentication, and at the same time introduces a way to insert entropy into TLS' key schedule such that the resulting protocol becomes resistant against attacks from quantum computers. We call this Quantum Relief, and specify it as part of a more general framework to make it easier for other technologies to achieve similar benefits. "Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan, Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2022-10-03, 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, 2022-10-04, 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, 2022-10-04, 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. "BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu, 2022-10-16, 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. "A MILP Model to Solve the Problem of Loading Balance of Routing and Wavelength Assignment for Optical Transport Networks", Shan Yin, Shanguo Huang, Dajiang Wang, Xuan Wang, Yu Zhang, 2022-10-23, The RWA problem can be formulated as a Mixed-Integer linear program. Load balancing is a key factor for the optical transport networks. However, the existed approaches using mixed-Integer linear program to solve the RWA problem are not perfect enough without considering the load balancing of the networks. This documentary provides a model of Mixed-Integer Linear Programming to solve the problem of load balancing needed by routing and wavelength assignment (RWA) process in optical transport networks. "Mathematical Mesh 3.0 Part I: Architecture Guide", Phillip Hallam-Baker, 2022-10-23, The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html. "Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira, 2022-10-04, This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is IPv4 mapped IPv6 address with plane ID. Unique allocation of plane id value enable 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, 2022-10-04, 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, 2022-10-04, 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, 2022-10-04, 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, 2022-10-04, 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, 2022-10-04, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Publishing Organization Boundaries in the DNS", John Levine, 2022-09-08, The organization that manages a subtree in the DNS is often different from the one that manages the tree above it. We describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models and can be queried with a small number of DNS lookups. "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2022-10-04, This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB make server load balancing over Layer3 network without packet header change at client and server. MSLB make server load balancing with any protocol and protocol with encription such as IPsec ESP, SSL/TLS. "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, 2022-07-10, 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 Path Computation Element Communication Protocol (PCEP). This document extends this capability for the Stateful PCEP messages. "Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets", Michael Tuexen, Randall Stewart, 2022-09-01, 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. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2022-11-10, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2022-10-04, This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is Ethernet mapped IPv6 address with plane ID. Unique allocation of plane id value enable duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. "ICANN TMCH functional specifications", Gustavo Ibarra, 2022-08-23, This document describes the requirements, the architecture and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. "OpenPGP Web Key Directory", Werner Koch, 2022-11-14, 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. "Multi-site EVPN based VXLAN using Border Gateways", Rajesh Sharma, Ayan Banerjee, Raghava Sivaramu, Ali Sajassi, 2022-06-23, This document described the procedures for interconnecting two or more Network Virtualization Overlays (NVOs) 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 and 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 [RFC7209] "Requirements for Ethernet VPN (EVPN)". In particular, this document describes the difference of the Gateways (GWs) procedure and incremental functionality from [RFC9014] "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks", which this solution is interoperable with. This document is OBSOLETE and replaced by [SHARMA-BESS-MULTI-SITE]. "Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2022-07-11, 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, 2022-07-11, 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, 2022-07-11, 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, 2022-10-05, [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]. "PCEP Extension for Distribution of Link-State and TE Information for Optical Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin-Yeong Yoon, 2022-09-05, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this Link State and TE information has been obtained from a link state routing protocol (supporting traffic engineering extensions). An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. "Fast HIP Host Mobility", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2022-06-17, This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. "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, 2022-07-01, 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). "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff Tantsura, 2022-07-06, BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features. "Adaptive IPv4 Address Space", Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe, 2022-06-10, 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. "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue, Richard Bradbury, Sam Hurst, 2022-07-04, This document specifies a profile of the QUIC protocol and the HTTP/3 mapping that facilitates the transfer of HTTP resources over multicast IP using the QUIC transport as its framing and packetisation layer. Compatibility with the QUIC protocol's syntax and semantics is maintained as far as practical and additional features are specified where this is not possible. "Cursor-based Pagination of SCIM Resources", Matt Peterson, Danny Zollner, 2022-10-01, This document defines additional SCIM 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. "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, JuneHee Kwon, Sandra Cespedes, 2022-07-25, 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, 2022-12-04, 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, 2022-07-01, 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.[ITU.G694.1] and its extensions and G.872.[ITU.G872]. "OSPF Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2022-07-11, 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, 2022-07-11, 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, 2022-12-06, 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. "The Hashed Token SASL Mechanism", Florian Schmaus, Christoph Egger, 2022-11-06, This document specifies the family of Hashed Token SASL mechanisms which enable a proof-of-possession-based authentication scheme and are meant to be used for quick re-authentication of a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round- trip property. The SASL mechanism specified herin further provides hash agility, mutual authentication and support for channel binding. "NEAT Sockets API", Thomas Dreibholz, 2022-08-23, 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. "Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator.", Alan DeKok, 2022-10-01, RADIUS uses a one-octet Identifier field to correlate requests and responses, which limits clients to 256 "in flight" packets per connection. This document removes that limitation by allowing Request Authenticator to be used as an additional field for identifying packets. The capability is negotiated on a per- connection basis, and requires no changes to the RADIUS packet format, attribute encoding, or data types. "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak, 2022-06-21, 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, 2022-10-11, 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, 2022-09-06, 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 MultiNexthop Attribute", Kaliraj Vairavakkalai, Jeyananth Jeganathan, Gyan Mishra, 2022-11-05, Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). For cases where multiple nexthops need to be advertised, BGP-Addpath is used. Though Addpath allows basic ability to advertise multiple- nexthops, it does not allow the sender to specify desired relationship between the multiple nexthops being advertised e.g., relative-preference, type of load-balancing. These are local decisions at the receiving speaker based on local configuration and path-selection between the various additional-paths, which may tie- break on some arbitrary step like Router-Id or BGP nexthop address. Some scenarios with a BGP-free core may benefit from having a mechanism, where egress-node can signal multiple-nexthops along with their relationship, in one BGP route, to ingress nodes. This document defines a new BGP attribute "MultiNexthop (MNH)" that can be used for this purpose. This attribute can be used for both labeled and unlabled BGP families. The MNH can be used to advertise MPLS label along with nexthop for unlabeled families (e.g. Inet Unicast, Inet6 Unicast). Such that, mechanisms at the transport layer can work uniformly on labeled and unlabled BGP families. Service route scale can be confined closer to the service edge nodes, making the transport layer nodes light and nimble. They dont have any service route state, only have service end-point state. The MNH plays different role in "downstream allocation" scenario than "upstream allocation" scenario. E.g. for [RFC8277] families that advertise downstream allocated labels, the MNH can play the "Label Descriptor" role, describing the forwarding semantics of the label being advertised. This can be useful in network visualization and controller based traffic engineering (e.g. EPE). "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu, 2022-06-17, Although several contemporary IT devices have multiple network interfaces, communication sessions are restricted to use only one of them at a time due to the design of the TCP/IP protocol stack: the communication endpoint is identified by an IP address and a TCP or UDP port number. The simultaneous use of these multiple interfaces for a communication session would improve user experience through higher throughput and improved resilience to network failures. MPT is a network layer multipath solution, which provides a tunnel over multiple paths using the GRE-in-UDP specification, thus being different from both MPTCP and Huawei's GRE Tunnel Bonding Protocol. MPT can also be used as a router, routing the packets among several networks between the tunnel endpoints, thus establishing a multipath site-to-site connection. The version of tunnel IP and the version of path IP are independent from each other, therefore MPT can also be used for IPv6 transition purposes. "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Ali Sajassi, Gaurav Badoni, Priyanka Warade, S. Pasupula, Lukas Krattiger, John Drake, Jorge Rabadan, 2022-09-02, This document proposes an EVPN extension to allow several of its multihoming functions, fast convergence and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri, 2022-09-11, 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. "HTTP Authentication with SASL", Rick van Rein, 2022-11-07, Most application-level protocols standardise their authentication exchanges under the SASL framework. HTTP has taken another course, and often ends up replicating the work to allow individual mechanisms. This specification adopts full SASL authentication into HTTP. "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, Mike Parker, Theodoros Rokkas, Mikhail Khokhlov, 2022-11-20, 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. "Simple Group Keying Protocol (SGKP)", Donald Eastlake, Dacheng Zhang, 2022-11-20, This document specifies a simple general group keying protocol that provides for the distribution of shared secret keys to group members and the management of such keys. It assumes that secure pairwise keys can be created between any two group members. "Registration Procedures for Private Enterprise Numbers (PENs)", Amanda Baber, Paul Hoffman, 2022-11-18, This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to request an update to a current PEN. It also gives a brief overview of PEN uses. "A YANG Data Model for Client-layer Tunnel", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2022-09-05, 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, 2022-10-24, 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. "Ground-Based LISP for the Aeronautical Telecommunications Network", Bernhard Haindl, Manfred Lindner, Victor Moreno, Marc Portoles-Comeras, Fabio Maino, Balaji Venkatachalapathy, 2022-09-23, This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures. "HTTP Live Streaming 2nd Edition", Roger Pantos, 2022-11-11, 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 10 of this protocol. "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin Cantrell, 2022-08-15, This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. "A feature freezer for the Concise Data Definition Language (CDDL)", Carsten Bormann, 2022-10-24, 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, 2022-07-30, 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, 2022-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). "Blockchain Transaction Protocol for Constraint Nodes", Pascal Urien, 2022-06-18, The goal of the blockchain transaction protocol for constraint nodes is to enable the generation of blockchain transactions by constraint nodes, according to the following principles: - transactions are triggered by Provisioning-Messages that include the needed blockchain parameters. - binary encoded transactions are returned in Transaction-Messages, which include sensors/actuators data. Constraint nodes, associated with blockchain addresses, compute the transaction signature. "Shared Brotli Compressed Data Format", Jyrki Alakuijala, Thai Duong, Evgenii Kliuchnikov, Robert Obryk, Zoltan Szabadka, Lode Vandevenne, 2022-09-28, This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window, patching and a container format to brotli [RFC7932]. Shared dictionaries and large window support allow significant compression gains compared to regular brotli, and patching allows smaller patches of binary files. "BGP Extended Community for Identifying the Target Nodes", Jie Dong, Shunwan Zhuang, Gunter Van de Velde, 2022-07-11, 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". The mechanism of using the Node Target Extended Community to steer BGP route distribution to particular BGP nodes is specified. "EVPN All Active Usage Enhancement", Donald Eastlake, Zhenbin Li, Haibo Wang, Russ White, 2022-12-05, 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. "Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering", Zafar Ali, Ketan Talaulikar, Clarence Filsfils, Nagendra Nainar, Carlos Pignataro, 2022-11-16, Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments. "EVPN VXLAN Bypass VTEP", Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ White, 2022-11-28, 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. "Origin Validation Policy Considerations for Dropping Invalid Routes", Kotikalapudi Sriram, Oliver Borchert, Doug Montgomery, 2022-11-27, Deployment of Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) is expected to occur gradually over several or many years. During the incremental deployment period, network operators would wish to have a meaningful policy for dropping Invalid routes. Their goal is to balance (A) dropping Invalid routes so hijacked routes can be eliminated, versus (B) tolerance for missing or erroneously created ROAs for customer prefixes. This document considers a Drop Invalid if Still Routable (DISR) policy that is based on these considerations. The key principle of DISR policy is that an Invalid route can be dropped if a Valid or NotFound route exists for a subsuming less specific prefix. "Traffic Accounting in Segment Routing Networks", Zafar Ali, Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, Dan Voyer, Rick Morton, 2022-11-16, Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric. "ICANN Registrar Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2022-09-13, 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. "IMAP Service Extension for Client Identity", Deion Yu, 2022-11-24, 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, 2022-07-27, This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. "DNS Web Service Discovery", Phillip Hallam-Baker, 2022-10-23, This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html. "Preferred Path Routing (PPR) in IS-IS", Uma Chunduri, Richard Li, Russ White, Luis Contreras, Jeff Tantsura, Yingzhen Qu, 2022-07-11, This document specifies a Preferred Path Routing (PPR), a routing protocol mechanism to simplify the path description using IS-IS protocol. PPR builds on existing encapsulation to add the path identity to the packet and supports further extensions along the preferred paths. PPR aims to provide path steering, services and support further extensions along the paths. Preferred path routing is achieved through the addition of path descriptions to the IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier. "Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space", Cheng Li, Hang Shi, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2022-11-10, The Path Computation Element Communication Protocol (PCEP) provides a mechanisms 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 provide 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 an 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 Enhanced VPN", Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Stewart Bryant, 2022-07-11, 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. "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark, 2022-11-06, 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, jeonghyeon kim, 2022-10-24, 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. "Design Discussion of Route Leaks Solution Methods", Kotikalapudi Sriram, 2022-09-06, This document captures the design rationale of the route leaks solution document (see draft-ietf-idr-route-leak-detection- mitigation, draft-ietf-grow-route-leak-detection-mitigation). The designers needed to balance many competing factors, and this document provides insights into the design questions and their resolution. "LURK Extension version 1 for (D)TLS 1.3 Authentication", Daniel Migault, 2022-08-24, This document defines a LURK extension for TLS 1.3 [RFC8446], with the specification of a Cryptographic Service (CS) for both the TLS client and the TLS server. "MPLS Network Actions using Post-Stack Extension Headers", Haoyu Song, Tianran Zhou, Loa Andersson, Zhaohui Zhang, Rakesh Gandhi, 2022-10-15, Motivated by the need to support multiple in-network services and functions in an MPLS network (a.k.a. MPLS Network Actions (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; each extension header is 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. This document confines to the solution of PAH encoding and leaves 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, 2022-10-16, 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: o Stream-oriented send-receive with native message boundary o Flexibility to exploit authenticated encryption o On-the-wire compression o Light-weight session management "The Multihash Data Format", Juan Benet, Manu Sporny, 2022-08-20, Cryptographic hash functions often have multiple output sizes and encodings. This variability makes it difficult for applications to examine a series of bytes and determine which hash function produced them. Multihash is a universal data format for encoding outputs from hash functions. It is useful to write applications that can simultaneously support different hash function outputs as well as upgrade their use of hashes over time; Multihash is intended to address these needs. "Access Extensions for ANCP", Hongyu Li, Thomas Haag, Birgit Witschurke, 2022-09-27, 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, 2022-09-05, 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. "Inband Flow Analyzer", Jai Kumar, Surendra Anubolu, John Lemon, Rajeev Manur, Hugh Holbrook, Anoop Ghanwani, Dezhong Cai, Heidi Ou, Yizhou Li, Xiaojun Wang, 2022-08-12, Inband Flow Analyzer (IFA) records flow specific information from an end station and/or switches across a network. This document discusses the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes a transport-agnostic header definition that may be used for tunneled and non-tunneled flows alike. "Postcard-Based On-Path Telemetry using Packet Marking", Haoyu Song, Greg Mirsky, Clarence Filsfils, Ahmed Abdelsalam, Tianran Zhou, Zhenbin Li, Thomas Graf, Gyan Mishra, Jongyoon Shin, Kyungtae Lee, 2022-11-28, The document describes a postcard-based on-path telemetry method using packet-marking, referred to as PBT-M. Similar to IOAM DEX, PBT-M does not carry the telemetry data in user packets but sends the telemetry data through a dedicated packet. However, PBT-M does not require an extra instruction header but claims a bit in existing header fields or uses some other equivalent means as a trigger for telemetry data processing and collection. Due to this feature, PBT-M raises some unique issues that need to be considered for its application in different networks. This document describes the high level scheme, summarizes the common requirements and issues, and provides recommendations for solutions. PBT-M is complementary to the other on-path telemetry schemes. "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola, Yisong Liu, Mauro Cociglio, Shinyoung Lee, Weidong Li, 2022-08-29, 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. "Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs", Mallory Knodel, Niels ten Oever, 2022-07-11, This document argues for more inclusive language conventions sometimes used by RFC authors and the RFC Production Centre in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series, in order to foster greater knowledge transfer and improve diversity of participation in the IETF. "Path Computation Element 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, 2022-07-10, The Path Computation Element (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. 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 for Segment Routing (SR) in IPv6 (SRv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID (Segment Identifier) allocation and distribution. "Path Computation Element 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, 2022-07-10, The Path Computation Element (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 Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. "Architecture for Use of BGP as Central Controller", Yujia Luo, Liang Ou, Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li, 2022-08-15, 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. "SR-TE Path Midpoint Restoration", Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu, Yisong Liu, 2022-10-24, Segment Routing Traffic Engineering (SR-TE) supports explicit paths using segment lists containing adjacency-SIDs, node-SIDs and binding- SIDs. The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node along a SR-TE path by the direct neighbor or say point of local repair (PLR) to the failure. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbors of the failure will no longer have a route to the failed node. This document describes a mechanism for the restoration of the routes to the failure of a SR-MPLS TE path after the IGP converges. It provides the restoration of the routes to an adjacency segment, a node segment and a binding segment of the path. With the restoration of the routes to the failure, the traffic is continuously sent to the neighbor of the failure after the IGP converges. The neighbor as a PLR fast re-routes the traffic around the failure. "AC-Aware Bundling Service Interface in EVPN", Ali Sajassi, Patrice Brissette, Mankamana Mishra, Samir Thoria, Jorge Rabadan, John Drake, 2022-09-12, EVPN provides an extensible and flexible multi-homing 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 IRB is one of the common deployment scenarios. There are deployments which requires capability to have multiple subnets designated with multiple VLAN IDs in 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 single Broadcast Domain. In this draft we define new service interface type to support multiple subnets in single Broadcast Domain. Service interface proposed in this draft will be applicable to multihoming case only. "Flowspec Indirection-id Redirect for SRv6", Gunter Van de Velde, Keyur Patel, Zhenbin Li, Huaimo Chen, 2022-07-11, 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. "A Framework for In-situ Flow Information Telemetry", Haoyu Song, Fengwei Qin, Huanan Chen, Jaewhan Jin, Jongyoon Shin, 2022-10-24, 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, Zafar Ali, Clarence Filsfils, Dan Voyer, Zhenbin Li, 2022-10-24, This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. "OAM for Service Programming with Segment Routing", Zafar Ali, Clarence Filsfils, Nagendra Nainar, Carlos Pignataro, Francois Clad, Faisal Iqbal, Xiaohu Xu, 2022-11-16, This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. "Segment Routing Header encapsulation for In-situ OAM Data", Zafar Ali, Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Nainar, Carlos Pignataro, Cheng Li, Mach Chen, Gaurav Dawra, 2022-07-10, OAM and PM information from the SR endpoints can be piggybacked in the data packet. The OAM and PM information piggybacking in the data packets is also known as In-situ OAM (IOAM). IOAM records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header. "Uberlay Interconnection of Multiple LISP overlays", Victor Moreno, Dino Farinacci, Alberto Rodriguez-Natal, Marc Portoles-Comeras, Fabio Maino, Sanjay Hooda, 2022-09-28, This document describes the use of the Locator/ID Separation Protocol (LISP) to interconnect multiple disparate and independent network overlays by using a transit overlay. The transit overlay is referred to as the "uberlay" and provides connectivity and control plane abstraction between different overlays. Each network overlay may use different control and data plane approaches and may be managed by a different organization. Structuring the network into multiple network overlays enables the interworking of different overlay approaches to data and control plane methods. The different network overlays are autonomous from a control and data plane perspective, this in turn enables failure survivability across overlay domains. This document specifies the mechanisms and procedures for the distribution of control plane information across overlay sites and in the uberlay as well as the lookup and forwarding procedures for unicast and multicast traffic within and across overlays. The specification also defines the procedures to support inter-overlay mobility of EIDs and their integration with the intra-overlay EID mobility procedures defined in draft-ietf-lisp-eid-mobility. "Realm Crossover for SASL and GSS-API via Diameter", Rick van Rein, 2022-10-14, SASL and GSS-API are used for authentication in many application protocols. This specification extends them to allow credentials of an identity domain to be used against external services. To this end, it introduces end-to-end encryption for SASL that is safe to relay through a foreign server. "Multiple Layer Resource Optimization for Optical as a Service", Hui Yang, Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang, 2022-10-17, We have established a neural network model optimized by adaptive artificial fish swarm algorithm. Then we propose a novel multi-path pre-reserved resource allocation strategy to increase resource utilization. The results prove the effectiveness of our method. "Security Classes for IoT devices", Pascal Urien, 2022-06-18, This draft attempts to define security classes for constraint IoT devices. A device security is characterized by five Boolean security attributes: one time programmable memory (OTP), firmware loader (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT- KEY) and diversified key (DIV-KEY). This leads to the definition of 6 classes of devices, embedding or not OTP resource, whose security increases with the class number (0 to 5). The suffix + indicates OTP availability. "The Multibase Data Format", Juan Benet, Manu Sporny, 2022-08-20, Raw binary data is often encoded using a mechanism that enables the data to be included in human-readable text-based formats. This mechanism is often referred to as "base-encoding the data". Base- encoding is often used when expressing binary data in hyperlinks, cryptographic keys in web pages, or security tokens in application software. There are a variety of base-encodings, such as base32, base58, and base64. It is not always possible to differentiate one base-encoding from another. The purpose of this specification is to provide a mechanism to be able to deterministically identify the base-encoding for a particular string of data. "CoRE Resource Directory Extensions", Christian Amsuess, 2022-07-11, 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. "OAM for LPWAN using Static Context Header Compression (SCHC)", Dominique Barthel, Laurent Toutain, Arunprabhu Kandasamy, Diego Dujovne, Juan Zuniga, 2022-10-24, With IP protocols now generalizing to constrained networks, users expect to be able to Operate, Administer and Maintain them with the familiar tools and protocols they already use on less constrained networks. OAM uses specific messages sent into the data plane to measure some parameters of a network. Most of the time, no explicit values are sent is these messages. Network parameters are obtained from the analysis of these specific messages. This can be used: * To detect if a host is up or down. * To measure the RTT and its variation over time. * To learn the path used by packets to reach a destination. OAM in LPWAN is a little bit trickier since the bandwidth is limited and extra traffic added by OAM can introduce perturbation on regular transmission. Two scenarios can be investigated: * OAM coming from internet. In that case, the NGW should act as a "General Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw, 2022-10-09, 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. "Options for MPLS Extension Header Indicator", Haoyu Song, Zhenbin Li, Tianran Zhou, Loa Andersson, 2022-06-27, This document enumerates and describes the candidate schemes that can be used to indicate the presence of the MPLS extension header(s) following the MPLS label stack. The similar schemes are also applicable for indicating the potential in-stack extensions. After a careful evaluation of these options by comparing their pros and cons, it is expected that one should be chosen as the final standard scheme for MPLS extension indicator. "IKEv2 Optional SA&TS Payloads in Child Exchange", Sandeep Kampati, Wei Pan, Paul Wouters, Bharath Meduri, chenmeiling, 2022-10-23, 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. "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip Hallam-Baker, 2022-10-23, This document describes the underlying naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. For convenience, UDFs are typically presented to the user in the form of a Base32 encoded string. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. "Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)", Phillip Hallam-Baker, 2022-10-23, This document describes the Data At Rest Encryption (DARE) Envelope and Sequence syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Sequence syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Sequences may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html. "The IPv6 Compact Routing Header (CRH)", Ron Bonica, Yuji Kamite, Andrew Alston, Daniam Henriques, Luay Jalil, 2022-11-14, This document defines two new Routing header types. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Sun Kj, Hyunsik Yang, Jangwon Lee, Tran Ngoc, Younghan Kim, 2022-09-22, 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 resource allocation and network technologies are specified for containerized VNFs. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. "Composite Signatures For Use In Internet PKI", Mike Ounsworth, Massimiliano Pala, 2022-06-08, The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptanalysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementer may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected. For digital signatures, this is referred to as "dual", and for encryption key establishment this as referred to as "hybrid". This document, and its companions, defines a specific instantiation of the dual and hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. EDNOTE: the terms "dual" and "hybrid" are currently in flux. We anticipate an Informational draft to normalize terminology, and will update this draft accordingly. This document defines the structures CompositeSignatureValue, and CompositeParams, which are sequences of the respective structure for each component algorithm. The generic composite variant is defined which allows arbitrary combinations of signature algorithms to be used in the CompositeSignatureValue and CompositeParams structures without needing the combination to be pre-registered or pre-agreed. The explicit variant is also defined which allows for a set of signature algorithm identifier OIDs to be registered together as an explicit composite signature algorithm and assigned an OID. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite public and private keys and encryption [I-D.draft-ounsworth-pq-composite-keys- 01], however may also be used with non-composite keys, such as when a protocol combines multiple certificates into a single cryptographic operation. "SRv6 Midpoint Protection", Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong Geng, Yisong Liu, Gyan Mishra, 2022-11-08, The current local repair mechanism, e.g., TI-LFA, allows local repair actions on the direct neighbors of the failed node or link to temporarily route traffic to the destination. This mechanism could not work properly when the failure happens in the destination point. In SRv6 TE, the IPv6 destination address in the outer IPv6 header could be the segment endpoint of the TE path rather than the destination of the TE path. When the SRv6 endpoint fails, local repair couldn't work on the direct neighbor of the failed endpoint either. This document defines midpoint protection for SRv6 TE path, which enables other nodes on the network to perform endpoint behaviors instead of the faulty node, update the IPv6 destination address to the other endpoint, and choose the next hop based on the new destination address. "Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence", Junkyun Choi, Jaeseob Han, Gyeong Lee, Jae Park, Chan Lee, Jung Lee, Hyeon Seo, 2022-06-28, This document describes the requirements and challenges to employ artificial intelligence (AI) into the constraint Internet of Things (IoT) service environment for embedding intelligence and increasing efficiency. The IoT service environment includes heterogeneous and multiple IoT devices and systems that work together in a cooperative and intelligent way to manage homes, buildings, and complex autonomous systems. Therefore, it is becoming very essential to integrate IoT and AI technologies to increase the synergy between them. However, there are several limitations to achieve AI enabled IoT as the availability of IoT devices is not always high, and IoT networks cannot guarantee a certain level of performance in real-time applications due to resource constraints. This document intends to present a right direction to empower AI in IoT for learning and analyzing the usage behaviors of IoT devices/systems and human behaviors based on previous records and experiences. With AI enabled IoT, the IoT service environment can be intelligently managed in order to compensate for the unexpected performance degradation often caused by abnormal situations. "BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf, Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2022-09-27, 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, 2022-10-23, 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, 2022-09-06, The 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 are able to produce attestation tokens as described in this memo, which are the basis for a number of 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 profiled 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. "Multi-Subject JSON Web Token (JWT)", Rifaat Shekh-Yusef, 2022-06-14, This specification defines a mechanism for including multiple subjects in a JWT. A primary subject in an enclosing JWT with its own claims, and a related secondary subject in a nested JWT with its own claims. "Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann, 2022-07-10, This document defines the method and bindings used to convey Evidence via Time-based Uni-Directional Attestation (TUDA) in Remote ATtestation procedureS (RATS). TUDA does not require a challenge- response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. TUDA enables the creation of Secure Audit Logs that can constitute believable Evidence about both current and past operational states of an Attester. In TUDA, RATS entities require access to a Handle Distributor to which a trustable and synchronized time-source is available. The Handle Distributor takes on the role of a Time Stamp Authority (TSA) to distribute Handles incorporating Time Stamp Tokens (TST) to the RATS entities. RATS require an Attesting Environment that generates believable Evidence. While a TPM is used as the corresponding root of trust in this specification, any other type of root of trust can be used with TUDA. "Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Hyeonah Jung, 2022-07-25, 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. "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip Hallam-Baker, 2022-10-23, The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the Mesh. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- cryptography.html. "Mathematical Mesh 3.0 Part V: Protocol Reference", Phillip Hallam-Baker, 2022-10-23, The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. "Mathematical Mesh 3.0 Part IV: Schema Reference", Phillip Hallam-Baker, 2022-10-23, The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. "IPv6 Neighbor Discovery on Wireless Networks", Pascal Thubert, 2022-10-11, This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media. "Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao, 2022-10-23, SRv6 inherits potential security vulnerabilities from Source Routing in general, and also from IPv6. This document describes various threats and security concerns related to SRv6 networks and existing approaches to solve these threats. "Design of the native Cyberspace Map", Jilong Wang, Miao Congcong, Changqing An, Shuying Zhuang, 2022-11-27, 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", Cheng Li, Ahmed El Sawaf, Ruizhao Hu, Zhenbin Li, 2022-10-23, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Service Function Chaining (SFC) provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification. SFC can be implemented based on several technologies, such as Network Service Header (NSH) and SR. This document describes a framework for constructing SFC based on Segment Routing. The document reviews the control plane solutions for route distribution of service function instance and service function path, and steering packets into a service function chain. "Guidelines for Internet Congestion Control at Endpoints", Gorry Fairhurst, 2022-10-24, 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 incipient congestion. The IETF provides recommendations and requirements on this topic that is distributed across many documents in the RFC series. This document therefore gathers and consolidates these recommendations. 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. "PCEP Operational Clarification", Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni, 2022-07-04, This document updates, simplifies and clarifies certain aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. "The Some Congestion Experienced ECN Codepoint", Jonathan Morton, Peter Heist, Rodney Grimes, 2022-10-14, This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE. It is a simple, transparent, and backward compatible upgrade to existing IETF-approved AQMs, RFC3168, and nearly all congestion control algorithms. "BMP Extension for Path Status TLV", Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf, 2022-10-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]. "Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework", Marco Tiloca, Rikard Hoeglund, Ludwig Seitz, Francesca Palombini, 2022-09-05, This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group OSCORE to provide communication security between a Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the public key of the Client associated with the private key used 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 correct 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. "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu, 2022-10-16, This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path. "Path Ingress Protections", Huaimo Chen, Mike McBride, Mehmet Toy, Gyan Mishra, Aijun Wang, Zhenqiang Li, Yisong Liu, Boris Khasanov, Lei Liu, Xufeng Liu, 2022-11-15, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for fast protecting the ingress nodes of two types of paths or tunnels, which are Segment Routing (SR) paths and Bit Index Explicit Replication Tree/Traffic Engineering (BIER-TE) paths. The extensions comprise a foundation for protecting the ingress nodes of different types of paths. Based on this, the ingress protection of a new type of paths can be easily supported. "Test Tools for IoT DDoS vulnerability scanning", Sorin Faibish, Mashruf Chowdhury, 2022-06-13, This document specifies several usecases related to the different ways IoT devices are exploited by malicious adversaries to instantiate Distributed Denial of Services (DDoS) attacks. The attacks are generted from IoT devices that have no proper protection against generating unsolicited communication messages targeting a certain network and creating large amounts of network traffic. The attackers take advantage of breaches in the configuration data in unprotected IoT devices exploited for DDoS attacks. The attackers take advantage of the IoT devices that can send network packets that were generated by malicious code that interacts with an OS implementation that runs on the IoT devices. The prupose of this draft is to present possible IoT DDoS usecases that need to be prevented by TEE. The major enabler of such attacks is related to IoT devices that have no OS or unprotected EE OS and run code that is downloaded to them from the TA and modified by man-in-the-middle that inserts malicious code in the OS. This draft adds list of MUD files for most IoT devices. "The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency", Bob Briscoe, Greg White, 2022-05-13, 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. "Distributed SFC control for fog environments", Carlos Bernardos, Alain Mourad, 2022-09-05, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document introduces the role of SFC pseudo- controller and specifies solutions to select and initialize such new logical function. "BGP Request for Candidate Paths of SR TE Policies", Zhenbin Li, Qiangzhou Gao, Huaimo Chen, Yanhe Fan, Xufeng Liu, Lei Liu, 2022-10-12, 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, 2022-06-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, 2022-09-06, This document describes a machine-readable format for specifying the syntax of protocol data units within a protocol specification. This format is comprised of a consistently formatted packet header diagram, followed by structured explanatory text. It is designed to maintain human readability while enabling support for automated parser generation from the specification document. This document is itself an example of how the format can be used. "SRv6 for Inter-Layer Network Programming", Jie Dong, Liuyan Han, Zongpeng Du, Minxue Wang, 2022-10-23, This document defines a new SRv6 function which can be used for SRv6 based inter-layer network programming. It is a variant of the SRv6 End.X behavior which is called "End.XU". 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 may be invisible in the L3 topology. "PCEP Extension for SR-MPLS Entropy Label Position", Quan Xiong, Shaofu Peng, Fengwei Qin, 2022-08-29, This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks. "Maintaining CCNx or NDN flow balance with highly variable data object sizes", David Oran, 2022-11-06, 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. "Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish, Philip Shilane, 2022-06-13, This document proposes extending NFSv4 operations to add new RECOMMENDED attributes to be used in the protocol to provide information about the data reduction properties of files. The new data reduction attributes are proposed to allow the client application to communicate to the NFSv4 server data reduction attributes associated with files and directories using new metadata, communicated to the Block Storage data reduction engines. Corresponding new RECOMMENDED attributes are proposed to allow clients and client applications to query the server for data reduction attributes support and allow to get and set data reduction attributes on files and directories. Such data reduction metadata is used as hints to the file server about what type of data reduction to apply. The proposed data reduction attributes include achievable ratios for compression and deduplication plus whether each data reduction technique applies to a file or directory. "YANG Data Model for OSPFv3 Segment Routing", Acee Lindem, Yingzhen Qu, 2022-10-21, This document defines a YANG data module augmenting the IETF OSPF Segment Routing (SR) YANG model to support OSPFv3 extensions for SR. It can be used to configure and manage OSPFv3 Segment Routing in MPLS data plane. "SRv6 NET-PGM extension: Insertion", Clarence Filsfils, Pablo Camarillo, John Leddy, Dan Voyer, Satoru Matsushima, Zhenbin Li, 2022-08-16, Traffic traversing an SR domain is encapsulated in an outer IPv6 header for its journey through the SR domain. To implement transport services strictly within the SR domain, the SR domain may require insertion or deletion of an SRH after the outer IPv6 header of the SR domain. Any segment within the SRH is strictly contained within the SR domain. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed only within the SR domain in any packet owned by the domain. "Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security", Valery Smyslov, 2022-11-10, An 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. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way get protection against quantum computers, but unlike the [RFC8784] solution it covers the initial IKEv2 SA too. "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay Hooda, 2022-10-18, 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). "Prefix Unreachable Announcement", Aijun Wang, Gyan Mishra, Zhibo Hu, Yaqun Xiao, 2022-07-10, This document describes a mechanism that can trigger the switchover of the services which rely on the reachability of the peer endpoints, for example the BGP or the tunnel services. It is mainly used in the scenarios that the summary prefixes are advertised at the border routers whereas the services endpoints are located in different IGP areas or levels, whose reachabilities are covered by the summary prefixes. It introduces a new signaling mechanism using a negative prefix announcement called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the overlay services that the event has occurred to force immediate switchover. "Lzip Compressed Format and the 'application/lzip' Media Type", Antonio Diaz, 2022-10-23, Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses a simplified form of the LZMA stream format and provides a 3 factor integrity checking to maximize interoperability and optimize safety. Lzip can achieve higher compression ratios than gzip. This document describes the lzip format and registers a media type, a content encoding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. "The Computerate Specifying Paradigm", Marc Petit-Huguenin, 2022-08-07, This document specifies a paradigm named Computerate Specifying, designed to simultaneously document and formally specify communication protocols. This paradigm can be applied to any document produced by any Standard Developing Organization (SDO), but this document targets specifically documents produced by the IETF. "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", Stanislav Smyshlyaev, Evgeny Alekseev, Ekaterina Griboedova, Alexandra Babueva, Lidiya Nikiforova, 2022-09-11, The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3. This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST algorithms, with Transport Layer Security (TLS) Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, key exchange mechanism described in this document. "EVPN-VPWS Seamless Integration with L2VPN VPWS", Patrice Brissette, Ali Sajassi, Luc Burdet, Wen Lin, Jorge Rabadan, Jim Uttaro, Dan Voyer, Iman Ghamari, Eddie Leyton, Bin Wen, Voitek Kozak, 2022-10-05, This document presents a solution for migrating L2VPN Virtual Private Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) services. The solution allows the coexistence of EVPN and L2VPN services under the same point-to-point VPN instance. By using this seamless integration solution, a service provider can introduce EVPN into their existing L2VPN network or migrate from an existing L2VPN based network to EVPN. The migration may be done per pseudowire or per flexible-crossconnect (FXC) service basis. This document specifies control-plane and forwarding behaviors. "Binary Structured HTTP Field Values", Mark Nottingham, 2022-10-11, This specification defines a binary serialisation of Structured Field Values for HTTP, along with a negotiation mechanism for its use in HTTP/2. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6", Xueshun Wang, Jinyou Dai, Jianhua Liu, Feng Zhang, 2022-06-18, 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, 2022-11-13, This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network. "A YANG Data Model for Client Signal Performance Monitoring", Haomian Zheng, Italo Busi, Zheng Yanlei, Victor Lopez, Oscar de Dios, 2022-07-10, 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. "Context-Aware Navigation Protocol for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, JuneHee Kwon, Zeung Kim, 2022-07-25, 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, Hyeonah Jung, J., PARK, Tae Oh, 2022-07-25, 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, Feng Zhao, Chongfeng Xie, Tong Li, Jichun Ma, Robbins Mwehair, Edmore Chingwena, Qingbang Xu, Shuping Peng, Tianran Zhou, Qiangzhou Gao, 2022-10-24, 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, 2022-08-24, 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. "Use of ALTO for Determining Service Edge", Luis Contreras, Danny Perez, Christian Rothenberg, Sabine Randriamasy, 2022-10-24, Service providers are starting to deploy and interconnect computing capabilities across the network for hosting network functions and applications. In distributed computing environments, both computing and topological information are necessary in order to determine the more convenient infrastructure where to deploy such a service or application. This document proposes an initial approach towards the use of ALTO to provide such information and assist the selection of appropriate deployment locations for services and applications. "Bijective MAC for Constraint Nodes", Pascal Urien, 2022-06-18, In this draft context, things are powered by micro controllers units (MCU) comprising a set of memories such as static RAM (SRAM), FLASH and EEPROM. The total memory size, ranges from 10KB to a few megabytes. In this context code and data integrity are major security issues, for the deployment of Internet of Things infrastructure. The goal of the bijective MAC (bMAC) is to compute an integrity value, which cannot be guessed by malicious software. In classical keyed MACs, MAC is computing according to a fixed order. In the bijective MAC, the content of N addresses is hashed according to a permutation P (i.e. bijective application). The bijective MAC key is the permutation P. The number of permutations for N addresses is N!. So the computation of the bMAC requires the knowledge of the whole space memory; this is trivial for genuine software, but could very difficult for corrupted software, especially for time stamped bMAC. "Deadline-aware Transport Protocol", Yong Cui, Chuan Ma, Hang Shi, Kai Zheng, Wei Wang, 2022-07-26, 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. "Negotiation of multiple Child Security Association with the Internet Key Exchange Protocol Version 2 (IKEv2)", Daniel Migault, Steffen Klassert, 2022-11-09, IPsec packet processing with one Security Association (SA) per core is more efficient than having a SA shared by the multiple cores. This document optimizes the negotiation of multiple unidirectional SAs so that each peer can assign one unidirectional SA per core. "Operational Considerations for BRSKI Registrar", Michael Richardson, Wei Pan, 2022-11-07, 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. "Operatonal Considerations for Voucher infrastructure for BRSKI MASA", Michael Richardson, Wei Pan, 2022-07-11, This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. "RPKI validated cache Update in SLURM over HTTPs (RUSH)", Di Ma, Hanbing Yan, Melchior Aelmans, Shicong Zhang, 2022-10-19, This document defines a method for transferring RPKI validated cache update information in JSON object format over HTTPs. "Abstract", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2022-06-17, This document specifies the format, contents and semantics of data escrow deposits for Industrial Internet Identifier Second-level Node (SLN). SLN directly serves enterprises and provides services such as identifier registration, identifier resolution, data sharing, etc. The mapping objects in this document mainly refers to the enterprise registration information of the SLN and the Enterprise-level Node (ELN) registered in the SLN. "Abstract", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2022-06-17, This document specifies the format and contents of data escrow deposits targeted primarily for Industrial Internet Identifier Node (IIIN) which provides identifier registration. However, this specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than IIIN. "HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2022-06-19, 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, 2022-06-19, 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, 2022-06-19, 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, 2022-06-19, 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, 2022-06-19, 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, 2022-11-23, 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. "Threshold Modes in Elliptic Curves", Phillip Hallam-Baker, 2022-10-23, Threshold cryptography operation modes are described with application to the Ed25519, Ed448, X25519 and X448 Elliptic Curves. Threshold key generation allows generation of keypairs to be divided between two or more parties with verifiable security guaranties. Threshold decryption allows elliptic curve key agreement to be divided between two or more parties such that all the parties must co-operate to complete a private key agreement operation. The same primitives may be applied to improve resistance to side channel attacks. A Threshold signature scheme is described in a separate document. https://mailarchive.ietf.org/arch/browse/cfrg/ (http://whatever)Discussion of this draft should take place on the CFRG mailing list (cfrg@irtf.org), which is archived at . "OSPF Graceful Restart Enhancements", Sami Boutros, Ankur Dubey, Vijayalaxmi Basavaraj, Acee Lindem, 2022-11-27, 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, 2022-07-24, 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, 2022-07-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, 2022-07-11, 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. "Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2022-12-06, This document defines a set of cryptographic transforms for use in the Internet Key Exchange protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (GOST). Use of GOST ciphers in IKEv2 was defined in RFC 9227. This document aims to define using GOST algorithms for the rest of cryptographic transforms used in IKEv2. This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document. "BGP Extension for SR-MPLS Entropy Label Position", Liu Yao, Shaofu Peng, 2022-06-07, This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. "Quic Timestamps For Measuring One-Way Delays", Christian Huitema, 2022-08-28, The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame. "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Christian Amsuess, 2022-07-11, 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. "Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, 2022-09-30, 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. "Problem Statement and Use Cases of Application-aware Networking (APN)", Zhenbin Li, Shuping Peng, Dan Voyer, Chongfeng Xie, Peng Liu, Zhuangzhuang Qin, Gyan Mishra, 2022-09-30, Network operators are facing the challenge of providing better network services for users. As the ever-developing 5G and industrial verticals evolve, more and more services that have diverse network requirements such as ultra-low latency and high reliability are emerging, and therefore differentiated service treatment is desired by users. On the other hand, as network technologies such as Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep evolving, the network has the capability to provide more fine- granularity differentiated services. However, network operators are typically unaware of the applications that are traversing their network infrastructure, which means that not very effective differentiated service treatment can be provided to the traffic flows. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network satisfying the fine- granularity requirements. This document analyzes the existing problems caused by lack of service awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) framework. "Signed Public Key and Challenge", Graham Leggett, Dirk-Willem van Gulik, 2022-10-22, This memo describes the Signed Public Key and Challenge (SPKAC), a syntax to provide Proof-of-Possession of a Private Key to support federated (client) certificate enrolment. "Conveying Transceiver-Related Information within RSVP-TE Signaling", Julien Meuric, Esther Le Rouzic, Luay Alahdab, Gabriele Galimberti, 2022-10-24, 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. "A User-Focused Internet Threat Model", Dominique Lazanski, 2022-07-03, RFC 3552 introduces a threat model that does not include endpoint security. Yet increasingly protocol development is making assumptions about endpoint security capabilities which have not been defined. RFC 3552 is 17 years old and threat landscape has changed. Security issues and cyber attacks have increased and there are more devices, users, and applications on the endpoint than ever. This draft proposes a new approach to the Internet threat model which will include endpoint security, focus on users and provide an update to the threat model in RFC 3552. It brings together Security Considerations for Protocol Designers draft-lazanski-protocol-sec-design-model-t-05 which is a comprehensive document that lists threats, attack vectors, examples and considerations for designing protocols, as well as draft-taddei-smart- cless-introduction-03 which lays out security concerns, capabilities and limitations for endpoints in general and draft-mcfadden-smart- endpoint-taxonomy-for-cless-02 which outlines a clear taxonomy for endpoint security and identifies changes in technology, economic and protocol development that has impacted and changed endpoint security. Taken together these drafts reflect a comprehensive and clear set of security threats and design considerations for the Internet. "No Further Fast Reroute", Kireeti Kompella, Wen Lin, 2022-07-08, 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, 2022-09-22, 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, 2022-09-22, 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, 2022-09-22, This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. "An Architecture for Network Function Interconnect", Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene, 2022-07-06, The emergence of technologies such as 5G, the Internet of Things (IoT), and Industry 4.0, coupled with the move towards network function virtualization, means that the service requirements demanded from networks are changing. This document describes an architecture for a Network Function Interconnect (NFIX) that allows for interworking of physical and virtual network functions in a unified and scalable manner across wide-area network and data center domains while maintaining the ability to deliver against SLAs. "Redundancy Policy for Redundancy Protection", Fan Yang, Xuesong Geng, Tianran Zhou, Gyan Mishra, 2022-07-24, This document introduces a variant of SR Policy called Redundancy Policy, in order to instruct the replication of service packets and assign more than one redundancy forwarding paths used for redundancy protection. "Distributed SFC control operation", Carlos Bernardos, Alain Mourad, 2022-09-11, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document describes a general framework for distributed SFC operation. "NSH extensions for local distributed SFC control", Carlos Bernardos, Alain Mourad, 2022-09-11, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies several NSH extensions to provide in-band SFC control signaling. "SFC function mobility with Mobile IPv6", Carlos Bernardos, Alain Mourad, 2022-09-11, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies Mobile IPv6 extensions to enable function migration in SFC. "Using Flex-Algo for Segment Routing (SR) based Virtual Transport Network (VTN)", Yongqing Zhu, Jie Dong, Zhibo Hu, 2022-07-11, Enhanced VPN (VPN+) aims to provide enhanced VPN service 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 as the underlay for one or a group of VPN+ services. The topological constraints of a VTN can be defined using Flex-Algo, a mechanism to provide distributed constraint-path computation. In some network scenarios, each VTN can be associated with a unique Flex-Algo, and the set of network resources allocated to a VTN can be instantiated as layer-2 sub-interfaces or member links of the layer-3 interfaces. This document describes the mechanisms to build the Segment Routing (SR) based VTNs using SR Flex-Algo and IGP L2 bundles with minor extensions. This document updates RFC 8668 by defining a new flag in the Parent L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV. "Security Considerations for Protocol Designers", Dominique Lazanski, 2022-07-03, This document is a non-exhaustive set of considerations for protocol designers and implementers with regards to attack defence. This document follows on from the way forward outlined in draft-lazanski- users-threat-model-t-04. These considerations both supplement and support the work on threat models. They can be used as an aid to analyse protocol design choice and in turn to help combat threats and defend users of these protocols and systems against malicious attacks. First, we list well-known classes of attacks that pose threats, with relevant case studies and descriptions. Next, we give a list of defence measures against these attacks to be considered when designing and deploying protocols. Naturally, deployments of protocols vary greatly between use cases; therefore, some attacks and defensive measures outlined may require more consideration than others, dependent on use case. This RFC can be used by protocol designers to write the Security Considerations section in an RFC. The impact on attack defence of a protocol should be considered in multiple use cases across the multiple layers of the internet. Defence against malicious attacks can be improved and it can be weakened by design features of protocols. Designers should acknowledge the role of protocols in attack prevention, detection and mitigation; this document aims to be a useful guide in doing so. "Auto-adjustment of Encapsulation Information in APN6", Zongpeng Du, Peng Liu, 2022-10-12, This document introduces a method to adjust the encapsulation information in Application-aware IPv6 Networking. "Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic", Zongpeng Du, Peng Liu, 2022-07-07, It is complex to support deterministic forwarding in a large scale network because there is too much dynamic traffic in the network and the data model becomes hard to predict after traffic aggregation on the intermediate nodes. This document introduces the problem of micro-bursts in the layer3 network, and analyses the method to decrease the micro-bursts in layer3 network for low-latency traffic. "Forwarding Layer Problem Statement", Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm, 2022-08-05, This document considers the problems that need to addressed in IP in order to address the use cases and new network services described in draft-bryant-arch-fwd-layer-uc-00. "MoWIE for Network Aware Application", Yuhang Jia, Yunfei Zhang, Richard Yang, Gang Li, Yixue Lei, Yunbo Han, Sabine Randriamasy, 2022-10-20, 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 with mobile and wireless device may vary, 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 dynamicity 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. Based on the evaluations, we discuss how the MoWIE features can define extensions of the ALTO protocol, to expose more lower-layer and finer grain network dynamics. "Connection-oriented Path in SRv6 Network", Zongpeng Du, Peng Liu, 2022-07-05, This document proposes a method to support connection-oriented path in the SRv6 network. Two related SRv6 Functions need to be supported on each node along the connection-oriented path. "SPAKE2+, an Augmented PAKE", Tim Taubert, Christopher Wood, 2022-05-05, This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime order group and is computationally efficient. This document was produced outside of the IETF and IRTF, and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. "Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk, 2022-09-05, 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 over IP multicast to a group of servers. 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. "IETF Network Slice Intent", Luis Contreras, Panagiotis Demestichas, Jeff Tantsura, 2022-10-24, Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introduction of new services such as 5G. This document explores the usage of intent technologies for requesting IETF network slices. "BGP Well Known Large Community", Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley, 2022-09-06, A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities. "Abstract", Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li, 2022-06-17, This document describes the Data Escrow report requirement and technical details of the interfaces provides by the Top-level Node (TLN) to its contracted parties. Second-level Node (SLN) MUST periodically send data escrow report to Top-level Node (TLN) and Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN and SLN after processing the report. "Crowd Sourced Remote ID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Shuai Zhao, Henk Birkholz, 2022-11-06, 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. "Reflexive Forwarding for CCNx and NDN Protocols", David Oran, Dirk Kutscher, 2022-11-28, 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, 2022-07-23, This document defines a transport mechanism for Unmanned Aircraft System (UAS) Network Remote ID (Net-RID). The Broadcast Remote ID (B-RID) 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. "QUIC Version Aliasing", Martin Duke, 2022-11-06, The QUIC transport protocol preserves its future extensibility partly by specifying its version number. There will be a relatively small number of published version numbers for the foreseeable future. This document provides a method for clients and servers to negotiate the use of other version numbers in subsequent connections and encrypts Initial Packets using secret keys instead of standard ones. If a sizeable subset of QUIC connections use this mechanism, this should prevent middlebox ossification around the current set of published version numbers and the contents of QUIC Initial packets, as well as improving the protocol's privacy properties. "LTP Fragmentation", Fred Templin, 2022-07-25, 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 maximum IP packet size for the path a service known as IP fragmentation must be employed. 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, 2022-11-07, 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 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. "Use Identity as Raw Public Key in EAP-TLS", chenmeiling, Li Su, Haiguang Wang, 2022-07-08, This document specifies the use of identity as a raw public key in EAP-TLS, EAP-TLS for TLS1.2 is defined in RFC 5216 and EAP-TLS for TLS1.3 is defined in the draft draft-ietf-emu-eap-tls13 and draft- ietf-tls-dtls13. The procedures of EAP-TIBS will consistent with EAP-TLS's interactive process, Identity-based signature will be extended to support EAP-TLS's signature algorithms. "Notable CBOR Tags", Carsten Bormann, 2022-07-11, 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 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, some 80 tag definitions 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. "Generalized SRv6 Network Programming for SRv6 Compression", Weiqiang Cheng, Zhenbin Li, Cheng Li, Francois Clad, Aihua Liu, Chongfeng Xie, Yisong Liu, Shay Zadok, 2022-10-23, This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming for SRv6 compression. G-SRv6 can reduce the overhead of SRv6 by encoding the Generalized SIDs(G-SID) in SID list, and it also supports to program SRv6 SIDs and G-SIDs in a single SRH to support incremental deployment and smooth upgrade. G-SRv6 is fully compatible with SRv6 with no modification of SRH, no new address consumption, no new route creation, and even no modification of control plane. G-SRv6 for Compression is designed based on the Compressed SRv6 Segment List Encoding in SRH [I-D.ietf-spring-srv6-srh-compression] framework. "Simple LISP NAT-Traversal Implementation", Dino Farinacci, 2022-09-11, This informational draft documents the lispers.net LISP NAT-Traversal implementation. "Defined Resource Operator (drop) The 'drop' URI Scheme", Tim McSweeney, 2022-08-15, This document describes the 'drop' Uniform Resource Identifier (URI) scheme. "The GNU Name System", Martin Schanzenbach, Christian Grothoff, Bernd Fix, 2022-08-07, This document contains the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols. This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations including with the pre- existing GNUnet implementation. "Identity Module for TLS Version 1.3", Pascal Urien, 2022-07-29, 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. "DTN Bundle Protocol Security (BPSec) COSE Context", Brian Sipos, 2022-09-14, 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. "Trusted Path Routing", Eric Voit, Chennakesava Gaddam, Guy Fedorkow, Henk Birkholz, chenmeiling, 2022-09-06, 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. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2022-11-16, 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. "Distributed Ledger Time-Stamp", Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano, 2022-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. "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, 2022-10-23, 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. "MPLS-based Service Function Path(SFP) Consistency Verification", Liu Yao, Greg Mirsky, 2022-06-11, This document describes extensions to MPLS LSP ping mechanisms to support verification between the control/management plane and the data plane state for SR-MPLS service programming and MPLS-based NSH SFC. This document defines the signaling of the Generic Associated Channel (G-ACh) over a Service Function Path (SFP) with an MPLS forwarding plane using the basic unit defined in RFC 8595. The document updates RFC 8595 in respect to SFF's handling TTL expiration. The document also describes the processing of the G-ACh by the elements of the SFP. "Principles for the Involvement of Intermediaries in Internet Protocols", Martin Thomson, 2022-09-08, This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide. "Seamless SR Problem Statement", Shraddha Hegde, Chris Bowers, Xiaohu Xu, Arkadiy Gulko, Alex Bogdanov, Jim Uttaro, Luay Jalil, Mazen Khaddam, Andrew Alston, Luis Contreras, 2022-07-08, This draft documents a set of use cases and requirements for end-to- end intent-based paths spanning multi-domain packet networks. The document explicitly focuses on use cases that require high scale and availability, which will likely benefit from distributed solutions. It is intended that the requirements in this document serve as a basis for future IETF work to develop distributed solutions for inter-domain intent-based transport paths. "TCP ACK Rate Request Option", Carles Gomez, Jon Crowcroft, 2022-10-12, 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. "Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM) Data", Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro, 2022-07-25, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path 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 fields are encapsulated in BIER header. "Accurate Data Scheduling by Server in MPTCP", Jiao Kang, liangqiandeng, Shangling Deng, 2022-06-16, This document defines a new mechanism that enables MPTCP server to send requests to MPTCP client for data scheduling between specified subflows during a MPTCP session. "Signal Degrade Indication in Segment Routing over MPLS Network", Liuyan Han, Fan Yang, Junfeng Zhao, 2022-07-07, 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. "Forwarding Layer Use Cases", Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm, 2022-08-06, This document considers the new and emerging use cases for IP. These use cases are difficult to address with IP in its current format and demonstrate the need to evolve the protocol. "A YANG Data Model for MPLS-TE Topology", Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Rakesh Gandhi, 2022-11-11, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) with Traffic Engineering (MPLS-TE) networks. "Interconnection Intents", Luis Contreras, Paolo Lucente, 2022-10-24, This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. "YANG Data Model for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro, Madhan Sankaranarayanan, Guangying Zheng, 2022-07-30, This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. "Cacheable OSCORE", Christian Amsuess, Marco Tiloca, 2022-07-11, 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, 2022-07-10, 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. "Autonomic Control Plane design for Layer-Two Switched Networks", Michael Richardson, Wei Pan, 2022-07-11, This document proposes a design for an L2 aware Autonomic Control Plane that can be deployed easily to layer-two (Ethernet) switched technologies that are common on Campus/Enterprise network architectures. This document leverages the hop-by-hop announcement used in LLDP, but runs bulk data over normal IPv6 Link-Local unicast ethernet frames. "Extensions to enable wireless reliability and availability in multi-access edge deployments", Carlos Bernardos, Alain Mourad, 2022-09-05, There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. "Mathematical Mesh 3.0 Part XI: Mesh Presence Service", Phillip Hallam-Baker, 2022-10-23, https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . "IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions", Venkata Munukutla, Shivam Vaid, Aditya Mahale, Devang Patel, 2022-08-09, This draft proposes 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, 2022-10-09, 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. "Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC)", Eduardo Sanchez, Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, 2022-07-11, The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-EDHOC with Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE (RFC 8152) to provide security services efficiently encoded in CBOR (RFC 8949). This document also provides guidance on authentication and authorization for EAP-EDHOC. "Fault Management Mechanism in MPTCP Session", Jiao Kang, liangqiandeng, Shangling Deng, 2022-06-16, This document presents a mechanism for fault management during a MPTCP session. It is used to convey subflow failure information from client to server by other subflow running normally. It includes: 1) a new Fault Announce Option for describing subflow failure, 2) implementation and interoperability of this option during a MPTCP session when one subflow suffers a failure. In fact, the server is able to determine network problems accurately based on these fault information reported from multiple clients for their connections. "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Michael Richardson, 2022-11-06, 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 "Usage scenarios of Application-aware Networking (APN) for SD-WAN", Feng Yang, Weiqiang Cheng, Shuping Peng, Zhenbin Li, 2022-11-13, This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a application group, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability. "Secure Element for TLS Version 1.3", Pascal Urien, 2022-09-28, 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. "InternetWide Identities with Realm Crossover", Rick van Rein, 2022-10-14, Domains and domain user identities are available in many protocols, and can be expressed as part of the URI grammar. This document outlines how clients can bring their self-controlled identities over when crossing over to foreign realms that rely on authenticated user identities. "Federated TLS Authentication", Jakob Schlyter, Stefan Halen, 2022-07-24, This document describes how to establish a secure end-to-end channel between two parties within a federation, where both client and server are mutually authenticated. The trust relationship is based upon a trust anchor held and published by the federation. A federation is a trusted third party that inter-connect different trust domains with a common set of policies and standards. "MSYNC", Sophie Bale, Remy Brebion, Guillaume Bichot, 2022-09-29, This document describes the Multicast Synchronization (MSYNC) Protocol that aims at transferring video media objects over IP multicast operating preferably RTP. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifest/playlists and media segments (e.g. MP4, CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH between a multicast server and a multicast gateway. "BGP Extensions of SR Policy for Segment List Identification and Protection", Liu Yao, Shaofu Peng, 2022-06-09, This document proposes extensions of BGP to provide identification and protection information of segment lists within a candidate path when delivering SR policy. And it also extends BGP-LS to provide some extra information of the segment list in the advertisement. "QUIC-Aware Proxying Using HTTP", Tommy Pauly, David Schinazi, 2022-10-21, 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. "Short Hierarchical IP Addresses for Edge Networks", Haoyu Song, 2022-10-10, To mitigate the IPv6 header overhead and improve the scalability and performance in edge networks, this draft proposes to use short hierarchical IP addresses excluding the network prefix within edge networks. An edge network can be further organized into a hierarchical architecture containing one or more levels of networks. While each end node only needs to keep a short address suffix as its identifier, the border routers for each hierarchical level are responsible for address augmenting and pruning when a packet leaves or enter a lower level network. Specifically, the top-level border routers of an edge network convert the internal IP header to and from the standard IPv6 header. This draft presents an incrementally deployable scheme allowing packet header to be effectively compressed in edge networks without affecting the network interoperability. Simplifying both network data plane and control plane, the SHIP architecture is suitable for any types of edge networks, especially when low latency, high performance, and high bandwidth efficiency are required. "User Devices Explicit Monitoring", Mauro Cociglio, Massimo Nilo, Fabio Bulgarella, Giuseppe Fioccola, 2022-10-13, This document describes a methodology to monitor network performance exploiting user devices. This can be achieved using the Explicit Flow Measurement Techniques, protocol independent methods that employ few marking bits, inside the header of each packet, for loss and delay measurement. User devices and servers, marking the traffic, signal these metrics to intermediate network observers allowing them to measure connection performance, and to locate the network segment where impairments happen. In addition or in alternative to network observers, a probe can be installed on the user device with remarkable benefits in terms of hardware deployment and measurement scalability. "Revised Cookie Processing in the IKEv2 Protocol", Valery Smyslov, 2022-10-12, 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. "An MPLS SR OAM option reducing the number of end-to-end path validations", Ruediger Geib, 2022-10-24, MPLS traceroute implementations validate dataplane connectivity and isolate faults by sending messages along every end-to-end Label Switched Path (LSP) combination between a source and a destination node. This requires a growing number of path validations in networks with a high number of equal cost paths between origin and destination. Segment Routing (SR) introduces MPLS topology awareness combined with Source Routing. By this combination, SR can be used to implement an MPLS traceroute option lowering the total number of LSP validations as compared to commodity MPLS traceroute. "Bidirectional Forwarding Detection (BFD) on Multi-chassis Link Aggregation Group (MC-LAG) Interfaces", Greg Mirsky, Jeff Tantsura, Gyan Mishra, 2022-09-25, This document describes the use of Bidirectional Forwarding Detection for Multi-chassis Link Aggregation Group to provide faster than Link Aggregation Control Protocol convergence. This specification enhances RFC 7130 "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces". "SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)", Gyan Mishra, Alexandre Petrescu, Naveen Kottapalli, Dusan Mudric, Dmytro Shytyi, 2022-11-10, This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 63 in PIO, for example, would be permitted to form an address whose interface identifier length is 65, which allows several benefits. A prefix of length 65 would be allowed too, but it SHOULD NOT be used on a large scale, like at a large ISP; this is to avoid a race to the bottom. The implementation uses a parameter in the Host; this option is off by default. In that case, the Host respects the 64bit boundary. When the parameter is set to on the Host accepts prefixes of lengths different than 64 and forms 128bit addresses. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. "SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement", Gyan Mishra, Alexandre Petrescu, Naveen Kottapalli, Dusan Mudric, Dmytro Shytyi, 2022-11-10, In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. "Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes", Xiao Min, Shaofu Peng, Liyan Gong, 2022-06-21, Path Segment is a type of 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. "Beyond 64KB Limit of IKEv2 Payloads", C. Tjhai, Tobias Heider, Valery Smyslov, 2022-07-28, The maximum Internet Key Exchange Version 2 (IKEv2) payload size is limited to 64KB. This makes IKEv2 not usable for conservative post- quantum cryptosystem whose public-key is larger than 64KB. This document discusses the considerations and defines a mechanism to exchange large post-quantum public keys and signatures in IKEv2. "Separation of Data Path and Data Flow Sublayers in the Transport Layer", Hirochika Asai, 2022-07-06, This document reviews the architectural design of the transport layer. In particular, this document proposes to separate the transport layer into two sublayers; the data path and the data flow layers. The data path layer provides functionality on the data path, such as connection handling, path quality and trajectory monitoring, waypoint management, and congestion control for the data path resource management. The data flow layer provides additional functionality upon the data path layer, such as flow control for the receive buffer management, retransmission for reliable data delivery, and transport layer security. The data path layer multiplexes multiple data flow layer protocols and provides data path information to the data flow layer to control data transmissions, such as prioritization and inverse multiplexing for multipath protocols. "Network measurement intent - one of IBN use cases", Danyang Chen, Hongwei Yang, Kehan Yao, Giuseppe Fioccola, Qin WU, Luis Contreras, 2022-10-23, 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 cannot match well. To solve this problem, this memo introduces network measurement intent, presents a process of scheduling the network resource and measurement task to meet the user or network operator's needs. And it can be seen as a specific use case of intent based network. "DC aware TE topology model", Young Lee, Xufeng Liu, Luis Contreras, 2022-07-11, This document proposes the extension of the TE topology model for including information related to data center resource capabilities. "IETF Network Slice Controller and its associated data models", Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody, Sergio Belotti, 2022-10-24, This document describes the 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. "Protocol and Engineering Effects of Consolidation", Dominique Lazanski, Mark McFadden, 2022-10-24, 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, a 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. "Security Management Automation of Cloud-Based Security Services in I2NSF Framework", Jaehoon Jeong, Patrick Lingga, J., PARK, Diego Lopez, Susan Hares, 2022-07-25, 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. "Transaction ID Mechanism for NETCONF", Jan Lindblad, 2022-06-08, 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. "Using Messaging Layer Security (MLS) to Provide Keys for SFrame", Richard Barnes, Raphael Robert, Suhas Nandakumar, 2022-10-24, Secure Frames (SFrame) defines a compact scheme for encrypting real- time media. In order for SFrame to address cases where media are exchanged among many participants (e.g., real-time conferencing), it needs to be augmented with a group key management protocol. The Messaging Layer Security (MLS) protocol provides continuous group authenticated key exchange, allowing a group of participants in a media session to authenticate each other and agree on a group key. This document defines how the group keys produced by MLS can be used with SFrame to secure real-time sessions for groups. "Mailing List Manager (MLM) Transformations", Alessandro Vesely, 2022-09-14, The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to rewrite the From: header field as a workaround. This document proposes three methods to get rid of munged From: lines. The methods vary requirements, complexity and success rates. Method one considers how MLMs can avoid From: munging for specific users. Methods two uses the Author: header field while method three tries to revert MLM transformations, in order to restore the original From: line after reception. "JWS Clear Text JSON Signature Option (JWS/CT)", Bret Jordan, Samuel Erdtman, Anders Rundgren, 2022-06-21, This document describes a method for extending the scope of the JSON Web Signature (JWS) specification, called JWS/CT (JWS "Clear Text"). By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed. In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging. The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward. This informational specification has been produced outside the IETF, is not an IETF standard, and does not have IETF consensus. The intended audiences of this document are JSON tool vendors as well as designers of JSON-based cryptographic solutions. "Network Time Protocol Version 5", Miroslav Lichvar, 2022-12-06, This document describes the version 5 of the Network Time Protocol (NTP). "IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White, Shraddha Hegde, Tony Przygienda, 2022-07-11, In dense topologies (such as data center fabrics based on the Clos and butterfly topologies, though not limited to these), IGP flooding mechanisms designed for sparse topologies can "overflood," or carry too many copies of topology and reachability information to fabric devices. This results in slower convergence times and higher resource utilization. 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 increasing convergence performance in dense topologies. 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 topology. "Trusted Resolution System and Protocol Extension", Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2022-11-07, The Handle System [1][2]is a name service system for handle resolution and management over the public Internet. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. This document describes a Trusted Resolution System and the protocol extension based on Handle System protocol. Trusted resolution aims to achieve credibility verification through data signing. The Trusted Resolution System determines whether to perform trusted resolution and verification on the response according to the trusted flag requested by the client. "Use of the SM2 and SM3 Algorithms in Handle System", Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2022-11-07, The Handle System is a global name service that allows secured handle resolution and administration over the public Internet according to [1][5][3]. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. In this document, SM2 and SM3 algorithms [4][5]are introduced into the handle system to enhance the security and compactivity. Trusted resolution and message credential are extended to support SM2 and SM3 algorithms. "In-band Edge-to-Edge Round Trip Time Measurement", Haoyu Song, Linda Dunbar, 2022-11-28, This draft describes a lightweight in-band in-network edge-to-edge flow-based network round trip time measurement architecture and proposes the implementation over IOAM E2E option. By augmenting the IOAM E2E option header, the process can be fully done in data plane without needing to involve the control plane to maintain any states. "SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li, 2022-08-07, 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. "JSON Schema: A Media Type for Describing JSON Documents", Austin Wright, Henry Andrews, Ben Hutton, Greg Dennis, 2022-06-10, JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", Austin Wright, Henry Andrews, Ben Hutton, 2022-06-10, JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like. "http2 window size setting", chenmeiling, Li Su, 2022-07-08, This document proposed the minimum value setting mechanism for HTTP2.0 Window and Window_update, and a Window_update frame sending mechanism, used to solve the gap caused by the inconsistency of the minimum value, f the use case when window_size_increment in the window update frame less than 128 bytes and the increased window size also less than 128 bytes, then network connection will come to an error. "APN Scope and Gap Analysis", Shuping Peng, Zhenbin Li, Gyan Mishra, 2022-09-07, The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an attribute allowing the implementation of fine-grain user group-level and application group- level requirements in the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, for example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to efficiently realize this composite network service provisioning along the path. This document further clarifies the scope of the APN work and describes the solution gap analysis. "SRv6 In-situ Active Measurement", Haoyu Song, Gyan Mishra, Tian Pan, 2022-09-06, 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. "Using Entropy Label for Network Slice Identification in MPLS networks.", Bruno Decraene, Clarence Filsfils, Wim Henderickx, Tarek Saad, Vishnu Beeram, Luay Jalil, 2022-06-14, This document updates [RFC6790] to extend the use of the TTL field of the Entropy Label in order to provide a flexible set of flags called the Entropy Label Control field. This document also defines a solution to encode a slice identifier in MPLS in order to distinguish packets that belong to different slices, to allow enforcing per network slice policies (.e.g, Qos). The slice identification is independent of the topology. It allows for QoS/DiffServ policy on a per slice basis in addition to the per packet QoS/DiffServ policy provided by the MPLS Traffic Class field. In order to minimize the size of the MPLS stack and to ease incremental deployment the slice identifier is encoded as part of the Entropy Label. "Photonic firewall oriented routing and spectrum allocation strategy in optical networks", Li Xin, Lu Zhang, Ying Tang, Zicheng Shi, Shanguo Huang, 2022-07-05, The photonic firewall oriented routing and spectrum allocation strategy in elastic optical networks is proposed. For the security detecting requirement, each light-path should pass through at least a photonic firewall. To reduce the blocking rate and improve the spectrum efficiency, the whole network is divided into several parts according to the locations of all deployed photonic firewalls. A photonic firewall is responsible for the security detecting for each part. This strategy has a low complexity and is suitable for large- scale optical networks. "A taxonomy of eavesdropping attacks", Michael Richardson, Jonathan Hoyland, 2022-10-23, The terms on-path attacker and Man-in-the-Middle Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. This document offers an update on terminology for network attacks. A consistent set of terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. "Architecture and application scenario for fused service function chain", Jinyou Dai, Xueshun Wang, Jun Gao, 2022-09-08, This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, 2022-09-29, 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 RFC 8881. 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. "SR-MPLS / SRv6 Transport Interworking", Shraddha Hegde, Parag Kaneriya, Ron Bonica, Shaofu Peng, Greg Mirsky, Zheng Zhang, Bruno Decraene, 2022-10-21, 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, 2022-08-09, This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". "Generic Delivery Functions", Zhaohui Zhang, Ron Bonica, Kireeti Kompella, Greg Mirsky, 2022-07-11, Some functionalities (e.g., fragmentation/reassembly and Encapsulating Security Payload) provided by IPv6 can be viewed as delivery functions independent of IPv6 or even IP entirely. This document proposes to provide those functionalities at different layers (e.g., MPLS, BIER or even Ethernet) independent of IP. "Segment Routing Header encapsulation for Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, 2022-08-05, This document describes how the Alternate Marking Method can be used as the passive performance measurement tool in an SRv6 network. It defines how Alternate Marking data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header. "Segment Routing for Unaffiliated BFD Echo Function", Mach Chen, Cheng Li, Jiang Wenying, Yisong Liu, Xinjun Chen, 2022-10-13, This document describes how to leverage Segment Routing (SR) to ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the remote system before being looped back to the local system. This enables that U-BFD works not only for one hop scenario but for multiple hops scenario as well. In addition, this document also defines a way to explicitly specify the loop back path of the U-BFD Echo packets. This is useful in the case where the forward and reverse path of the Echo packets are required to follow the same path. "Dynamic-Anycast (Dyncast) Problem Statement and Use Cases", Peng Liu, Philip Eardley, Dirk Trossen, Mohamed Boucadair, Luis Contreras, Cheng Li, Yizhou Li, 2022-07-08, Many service providers have been exploring distributed computing techniques to achieve better service response time and optimized energy consumption. Such techniques rely upon the distribution of computing services and capabilities over many locations in the network, such as its edge, the metro region, virtualized central office, and other locations. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities (e.g., edges) is being considered, e.g., for computationally intensive and delay sensitive services. Ideally, services should be computationally balanced using service-specific metrics instead of simply dispatching the service requests in a static way or optimizing solely connectivity metrics. For example, systematically directing end user-originated service requests to the geographically closest edge or some small computing units may lead to an unbalanced usage of computing resources, which may then degrade both the user experience and the overall service performance. We have named this kind of network with dynamic sharing of edge compute resources "Computing-Aware Networking" (CAN). This document provides the problem statement and the typical scenarios of CAN, which is to provide the service equivalency by steering traffic dynamically to the appropriate service instance based on the basic edge computing deployment. "BGP Extensions of SR Policy for Composite Candidate Path", Hao Li, Mengxiao Chen, Changwang Lin, Jiang Wenying, Weiqiang Cheng, 2022-08-30, 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, 2022-08-30, 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. "Aggregated Option for SYN Option Space Extension", Yoshifumi Nishida, 2022-10-23, TCP option space is scarce resource as its max length is limited to 40 bytes. This limitation becomes more significant in SYN segments as all options used in a connection should be exchanged during SYN negotiations. This document proposes a new SYN option negotiation scheme that can aggregate multiple TCP options in SYN segments into a single option so that more options can be negotiate during 3 way handshake. With its simple design, the approach does not require fundamental changes in TCP. "PCEP Extensions for sid verification for SR-MPLS", Ran Chen, Samuel Sidor, Chun Zhu, Alexej Tokar, Mike Koldychev, 2022-07-27, This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. "Subtype Capability Exchange During MPTCP Handshake", Jiao Kang, liangqiandeng, Shangling Deng, 2022-06-16, Multipath TCP provides the ability to simultaneously use multiple paths between peers. MPTCP protocol defines seven subtypes in MPTCP v0 [RFC6824] and ten subtypes in MPTCP v1 [RFC8684] to differentiate message types and implement some additional functions during a session. This draft proposes an enhancement to support Subtype Capability Exchange during MPTCP connection establishment in order to improve elastic scalability of MPTCP protocol. It includes: 1) requirements for which this kind of capability exchange during handshake is important for a MPTCP session; 2) a typical flow for Subtype Capability Exchange between peers; 3) a feasible solution on protocol design is suggested. "Simple Two-Way Direct Loss Measurement Procedure", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Stefano Salsano, 2022-08-08, 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. "Dynamic-Anycast Architecture", Yizhou Li, Luigi Iannone, Dirk Trossen, Peng Liu, Cheng Li, 2022-07-10, This document describes a proposal for an architecture for the Dynamic-Anycast (Dyncast). It includes an architecture overview, main components that shall exist, and the workflow. An example of workflow is provided, focusing on the load-balance multi-edge based service use-case, where load is distributed in terms of both computing and networking resources through the dynamic anycast architecture. "An Offset Extension Frame For HTTP/3 Data", Sam Hurst, 2022-07-04, This document specifies an optional extension frame type for HTTP/3 that extends the functionality of the DATA frame type to include an offset for the HTTP message payload. This is useful in situations where the HTTP/3 exchange is taking place over an unreliable transport mechanism. "Integrated Operation, Administration, and Maintenance", Greg Mirsky, Xiao Min, Gyan Mishra, 2022-11-10, This document describes the Integrated Operation, Administration, and Maintenance (IntOAM) protocol. IntOAM is based on the lightweight capabilities of Bidirectional Forwarding Detection defined in RFC 5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss and Delay Measurement for MPLS Networks to measure performance metrics like packet loss and packet delay. Also, a method to perform lightweight on-demand authentication is defined in this specification. "PCE for BIER-TE Path", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-10-16, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for supporting Bit Index Explicit Replication (BIER) Traffic Engineering (TE) paths. "BIER-TE Fast ReRoute", Huaimo Chen, Mike McBride, Yisong Liu, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-08-15, 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, 2022-08-15, 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. "Terminal-based joint selection and configuration of MEC host and RAW network", Carlos Bernardos, Alain Mourad, 2022-09-11, There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. "Carrying Virtual Transport Network (VTN) Information in MPLS Packet", Zhenbin Li, Jie Dong, 2022-10-16, A Virtual Transport Network (VTN) is a virtual network which has a customized network topology and a set of dedicated or shared network resources allocated from the underlying physical network. Multiple VTNs can be created by network operator for using as the underlay for one or a group of VPNs services to provide enhanced VPN (VPN+) services. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be executed on the packet. In the context of network slicing, a VTN can be instantiated as a Network Resource Partition (NRP). This document proposes a mechanism to carry the data plane VTN ID in an MPLS packet to identify the VTN the packet belongs to. The procedure for processing the VTN ID is also specified. "Dynamically Recreatable Keys", Juan Garcia-Pardo, Cyrill Kraehenbuehl, Benjamin Rothenberger, Adrian Perrig, 2022-07-24, DRKey is a pragmatic Internet-scale key-establishment system that allows any host to locally obtain a symmetric key to enable a remote service to perform source-address authentication, and enables first- packet authentication. The remote service can itself locally derive the same key with efficient cryptographic operations. DRKey was developed with path aware networks in mind, but it is also applicable to today's Internet. It can be incrementally deployed and it offers incentives to the parties using it independently of its dissemination in the network. "NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol", Martin Langer, Rainer Bermbach, 2022-08-22, This document defines a key management service for automatic key management for the integrated security mechanism (prong A) of IEEE Std 1588[TM]-2019 (PTPv2.1) described there in Annex P. It implements a key management for the immediate security processing approach and offers a security solution for all relevant PTP modes. The key management service for PTP is based on and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTP, but works completely independent from NTP. "Multi-purpose Special Purpose Label for Forwarding Actions", Kireeti Kompella, Vishnu Beeram, Tarek Saad, Israel Meilik, 2022-07-10, The MPLS architecture introduced Special Purpose Labels (SPLs) to indicate special forwarding actions and offered a few simple examples, such as Router Alert. In the two decades since the original architecture was crafted, the range, complexity and sheer number of such actions has grown; in addition, there now is need for "associated data" for some of the forwarding actions. Likewise, the capabilities and scale of forwarding engines has also improved vastly over the same time period. There is a pressing need to match the needs with the capabilities to deliver the next generation of MPLS architecture. In this memo, we propose an alternate mechanism whereby a single SPL can encode multiple forwarding actions and carry data (if any) associated with the actions, some in the label stack and some after the label stack. This proposal also solves the problem of scarcity of base SPLs. As proof of its utility and flexibility, this approach can immediately address several use cases: * to carry an Entropy Label for better load balancing; * to carry a Flow-Aggregate Selector for IETF network slicing; * to signal that further fast reroute may have harmful consequences; * to indicate that there is relevant data after the label stack; * among others. "SRH and IP header protection", Dongjie Lu, chenmeiling, Li Su, Wei Pan, Cheng Li, 2022-10-15, This document proposes a method to protect SRH and IP header using signature which stored in the TLV, this scheme can apply to SRv6 and G-SRv6. By defining a new type of TLV which is used for signature protection based on asymmetric secret keys. Of course, we have designed the process of signature and verification, and tips for verifying optimization process. "Instantiation of IETF Network Slices in Service Providers Networks", Samier Barguil, Luis Contreras, Victor Lopez, Reza Rokui, Oscar de Dios, 2022-10-24, Network Slicing (NS) is an integral part of Service Provider networks. The IETF has produced several YANG data models to support the Software-Defined Networking and network slice architecture and YANG-based service models for network slice (NS) instantiation. This document describes the relationship between IETF Network Slice models for requesting the IETF Network Slices (i.e. the IETF Network Slice YANG model) and both Service (e.g., Layer-3 Service Model, Layer-2 Service Model) and Network (e.g., Layer-3 Network Model, Layer-2 Network Model) models used during their realizations. In addition, this document describes the communication between the IETF Network Slice Controller and the network controllers for the realization of IETF network slices. The IETF Network Slice YANG model provides the customer-oriented view of the network slice. Thus, once the IETF Network Slice controller (NSC) receives a request, the NSC needs to map such request to accomplish the specific parameters expected by the network controllers. The network models are analyzed to satisfy the IETF Network Slice requirements, and the gaps in existing models are reported. The document also provides operational and security considerations when deploying network slices in Service Provider networks. "Automatically Connecting Stub Networks to Unmanaged Infrastructure", Ted Lemon, 2022-11-10, 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). "Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation", Carsten Bormann, 2022-10-24, 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, 2022-06-13, 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. "Prague Congestion Control", Koen De Schepper, Olivier Tilmans, Bob Briscoe, 2022-07-11, 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 the current default options of the reference Linux implementation of TCP Prague, but it includes experience from other implementations where available. It separately describes non-default and optional parts, as well as future plans. 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. In two cases, research code is replaced by placeholders until full evaluation is complete. "Status of This Memo", Charles Edge, 2022-09-26, Many Service Providers offer application configuration options that manage the state of applications on mobile devices. AppConfig is used to distribute settings to applications upon installation or updated arbitrarily via a trusted Mobile Device Management (MDM) service. This document defines the specification by allowing a standardized format for data to stream into applications via XML (RFC 3470) or JSON interfaces (RFC 4627). "A SIP Response Code (497) for Call Transfer Failure", Shrawan Khatri, Vikram Singh, Marcelo Pazos, Cherng-Shung Hsu, 2022-07-25, This document defines the 497 (Call Transfer Failure) SIP response code, allowing Call Pull and Call Push parties to indicate that the operation was rejected. Optional warning codes are defined to carry granular information. SIP entities may use this information to adjust how subsequent calls can be handled intelligently. "Security Technical Specification for Smart Devices of IoT", Bin Wang, Xing Wang, Li Wan, Wenyuan Xu, Chonghua Wang, 2022-09-12, With the development of IoT, security of smart devices becomes 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 includes firmware security, security audit, etc. Data security includes data verification and sensitive data protection. Network security includes stream protection and session security, etc. "Technical Requirements for Secure Access and Management of IoT Smart Terminals", Bin Wang, Song Liu, Li Wan, Jun Li, Xing Wang, 2022-09-12, 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. "LISP Transport for Policy Distribution", Michael Kowal, Marc Portoles-Comeras, Amit Jain, Dino Farinacci, 2022-09-28, This document describes the use of the Locator/ID Separation Protocol (LISP) to encode and transport data models for the configuration of LISP ITRs. "Open Service Access Protocol for IoT Smart Devices", Bin Wang, Shaopeng Zhou, Chao Li, Chunming Wu, Zizhao Wang, 2022-09-12, With the development of IoT(Internet of Things) technology, everything is interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues, such as data heterogeneous, device heterogeneous, and application heterogeneous, which hinders the development of the industry. In order to solve the problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is for the program design, system testing and acceptance, and related research. Structured, unified, and standardized open service interconnection model reduces business replication cost and removes service barriers to push industrial development. "The LIMITS SMTP Service Extension", pradeep xplorer, 2022-11-07, To allow wild card emailing like walling "Fetch and Validation of Verified Mark Certificates", Wei Chuang, Marc Bradshaw, Thede Loder, Alex Brotman, 2022-10-09, 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, 2022-10-09, 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. "Deprecating infrastructure "int" domains", Kim Davies, Amanda Baber, 2022-11-28, The document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and identifies them for removal from the "int" top-level domain. Any implementation that involves these domains should be considered deprecated. This document also requests moving the status of RFC 1528 and RFC 1706 to historic. "Common Format and MIME Type for Comma-Separated Values (CSV) Files", Yakov Shafranovich, 2022-09-14, This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". "DNS Resolver Information", Tirumaleswar Reddy.K, Mohamed Boucadair, 2022-08-31, 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. "Mathematical Mesh 3.0 Part VII: Mesh Callsign Service", Phillip Hallam-Baker, 2022-10-23, The Mesh Callsign Registry is a name registry that provides a mapping from human-friendly callsigns to root of trusts and a service assigned by the callsign holder to service the account bound to that callsign. An append only sequence authenticated by means of a Merkle Tree and periodic third party notarizations provides ground truth for the integrity of the registry and for all the assertions enrolled in the sequence. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . "LAG indication", Bruno Decraene, Shraddha Hegde, Joel Halpern, 2022-08-01, This document defines a new link flag to advertise that a layer-three link is composed of multiple layer-two sub-links, such as when this link is a Link Aggregation Group (LAG). This allows a large single flow (an elephant flow) to be aware that the link capacity will be lower than expected as this single flow is not load-balanced across the multiple layer-two sub-links. A path computation logic may use that information to route that elephant flow along a different path. "ND Prefix Robustness Improvements", Eduard, Paolo Volpato, Loba Olopade, 2022-09-01, IPv6 prefixes could become invalid abruptly as a result of outages, network administrator actions, or particular product shortcomings. That could lead to connectivity problems for the hosts attached to the subtended network. This document has two targets: on one hand, to analyze the cases that may lead to network prefix invalidity; on the other to develop a root cause analysis for those cases and propose a solution. This may bring to extensions of the protocols used to convey prefix information and other options. This document updates RFC 4861 and RFC 4862. "Data Transmission Security of Identity Resolution in Industrial Internet", Bin Wang, Kezhang Lin, Chonghua Wang, Xing Wang, 2022-09-12, This draft provides an overview of the security of data transmission in the identity resolution system for the Industrial Internet. Identity resolution systems play a vital role in the Industrial Internet by providing secure sharing and intelligent association of heterogeneous information among different organizations. This draft focuses on the security services that identity resolution systems should provide for resolution data transmission. "Border Gateway Protocol 4 (BGP-4) Send Hold Timer", Job Snijders, Ben Cartwright-Cox, 2022-08-19, This document defines the SendHoldTimer session attribute for the Border Gateway Protocol (BGP) Finite State Machine (FSM). Implementation of a SendHoldTimer should help overcome situations where BGP sessions are not terminated after it has become detectable for the local system that the remote system is not processing BGP messages. For robustness, this document specifies that the local system should close BGP connections and not solely rely on the remote system for session closure when BGP timers have expired. This document updates RFC4271. "Retrieving information about Object Identifiers using a text-based protocol", Daniel Marschall, 2022-07-24, 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. "Segment Routing for End-to-End IETF Network Slicing", Zhenbin Li, Jie Dong, Ran Pang, Yongqing Zhu, 2022-10-24, IETF network slices can be used to meet the connectivity and performance requirements of different services or customers in a shared network. An IETF network slice can be realized by mapping a set of connectivity constructs to a network resource partition (NRP). In some network scenarios, an end-to-end IETF network slice may span multiple network domains. Within each domain, traffic of the end-to- end network slice service is mapped to an intra-domain NRP. When segment routing (SR) is used to provide multi-domain IETF network slices, information of the intra-domain NRP can be specified using special SR binding segments which are called NRP binding segments (NRP BSID). Then a multi-domain IETF network slice can be specified using a list of NRP BSIDs in the packet, each of which is used by the corresponding domain edge nodes to steer the traffic of the end-to-end IETF network slice into the specific intra-domain NRP. This document describes the functionality of the NRP binding segment and its instantiation in SR-MPLS and SRv6 data planes. "Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou, Lifen Zhou, 2022-06-18, 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). "Generating Password-based Keys Using the GOST Algorithms", Karelina Ekaterina, 2022-09-28, This document specifies how to use the Password-Based Cryptography Specification version 2.1 (PKCS #5) defined in RFC8018 to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms. PKCS #5 applies a pseudorandom function (a cryptographic hash, cipher, or HMAC) to the input password along with a salt value and repeats the process many times to produce a derived key. This specification is developed outside the IETF and is published to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document. "Internet of Secure Elements", Pascal Urien, 2022-10-04, 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). "Discovery of Encrypted DNS Resolvers: Deployment Considerations", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook, Tommy Jensen, 2022-10-18, The document discusses some deployment considerations of the various options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-TLS, or DNS-over-QUIC). In particular, the document describes how Discovery of Network-designated Resolvers (DNR) and Discovery of Designated Resolvers (DDR) can be used in typical deployment contexts. This document does not intend to provide deployment recommendations, but is meant to exemplify how operators can enable the encrypted DNS discovery mechanisms. In addition, the document illustrates the feasibility of hosting encrypted DNS forwarders in Customer Premises Equipment (CPEs). "Use of an MPLS LSE as an Ancillary Data Pointer", Stewart Bryant, Alexander Clemm, Toerless Eckert, 2022-08-06, The purpose of this memo is to describe how Label Stack Entries (LSEs) can be used to point to ancillary or meta-data carried below the MPLS label stack. "HESP - High Efficiency Streaming Protocol", Pieter-Jan Speelmans, 2022-11-14, 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 1 of this protocol. "BGP Flow Specification for DetNet and TSN Flow Mapping", Quan Xiong, Haisheng Wu, Junfeng Zhao, Dong Yang, 2022-09-13, 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. "Deterministic Networking (DetNet): OAM Functions for The Service Sub-Layer", Balazs Varga, Janos Farkas, Greg Mirsky, 2022-07-25, Operation, Administration, and Maintenance (OAM) tools are essential for a deterministic network. The DetNet architecture [RFC8655] has defined two sub-layers: (1) DetNet service sub-layer and (2) DetNet forwarding sub-layer. OAM mechanisms exist for the DetNet forwarding sub-layer. Nonetheless, OAM for the service sub-layer might require new extensions to the existing OAM protocols. This draft presents an analysis of OAM procedures for the DetNet service sub-layer functions. "Gateway Identification and Discovery", Shiping Chen, Thomas Hardjono, Qin Wang, 2022-08-15, [SATP] is a secure asset transfer protocol that operates between two gateways. This memo describes requirements, standards and architectural options that can be considered to identify, discover and verify gateways before transferring secure digital assets via SATP. "Sliding Window Selective Linear Code (SLC) Forward Error Correction (FEC) Scheme for FECFRAME", Ray Wang, Liang Si, Bifeng He, 2022-06-14, RFC8680 describes a framework for using Sliding Window Forward Error Correction(FEC) codes to protection against packet loss, the framework significantly improves FEC efficiency and reduces FEC- related added latency compared to block FEC codes defined in RFC 6363. RFC8681 further describes two fully specified FEC schemes for Sliding Window Random Linear Codes(RLC), the schemes rely on an encoding window that slides over a continuous set of source symbols, generating new repair symbols whenever needed. This document describes a fully specified FEC scheme for Sliding Window Selective Linear Code(SLC) over the Galois Field GF (2^^8) , compared to RFC8681, this framework use a discrete encoding window which can protect arbitrary media streams selectively, and has better recovery performance in scenarios such as layered video coding or mixed streams for video streaming applications. "Problem Statement and Use Cases of Trustworthiness-based Routing", Tao Lin, Hao Li, Xingang Shi, Xia Yin, Wenlong Chen, 2022-06-14, 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", Liu Yao, Zheng Zhang, Eduard Metz, 2022-06-14, This draft describes the problems that may be encountered during the deployment of SRv6-based BGP services and the possible solutions. "Multi Distribution master", haisheng yu, Daobiao Gong, Yang Song, Yan Liu, 2022-06-19, DM (Distribution Master) is used to transfer zone file data between the registry and the authoritative server. The centralized DM system has the risk of a single point of failure. The distributed DM architecture allows nodes to join and exit at any time to solve the single point of failure problem. "Complaint Feedback Loop Address Header", Jan-Philipp Benecke, 2022-11-14, This document describes a method that allows an email sender to specify a complaint feedback loop (FBL) address as an email header. Also, it defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide mailbox providers with an address for a complaint feedback loop. Currently, providing and maintaining such an address is a manual and time-consuming process for email senders and providers. It is unclear, at the time of publication, whether the function provided by this document has widespread demand, and whether the mechanism offered will be adopted and found to be useful. Therefore, this is being published as an Experiment, looking for a constituency of implementers and deployers, and for feedback on the operational utility. The document is produced through the Independent RFC stream and was not subject to the IETF's approval process. "Problems and Requirements of Satellite Constellation for Internet", Lin Han, Richard Li, Alvaro Retana, chenmeiling, Li Su, Tianji Jiang, Ning Wang, 2022-07-06, 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. "Applications Multiplexing a QUIC Session", Jiao Kang, liangqiandeng, Shangling Deng, Peng Liu, 2022-06-16, This document describes the requirements for extensions on QUIC transport protocol in the use case when multiple application protocols reuse the same QUIC session for data transmission. "Supporting leaves without northbound neighbors connecting to a fat-tree network using RIFT", Zheng Zhang, Yuehua Wei, BenChong Xu, 2022-07-03, This document discusses the usage and solution for leaf nodes without northbound neighbors connecting to a fat-tree network by leaf nodes having direct northbound neighbors in RIFT. "BGP Dissemination of FlowSpec for Transport Aware Mobility", Linda Dunbar, Kausik Majumdar, Uma Chunduri, 2022-06-27, This document defines a BGP Flow Specification (flowSpec) extension to disseminate flows from 5G mobile networks so that the 5G mobile systems slices and Service Types (SSTs) can be mapped to optimal underlying network paths in the data network outside the 5G UPFs, or the N6 interface in 3GPP 5G Architecture [3GPP TR 23.501]. "Verification of Routes Using Region Authorization", Chen Shen, Tianran Zhou, Yisong Liu, Wenyan Yu, Haibo Wang, Shunwan Zhuang, Shuanglong Chen, 2022-08-16, BGP routing security is becoming a major issue that affects the normal running of Internet services. Currently, there are many solutions, including ROA authentication and ASPA authentication, to prevent route source hijacking, path hijacking, and route leaking. However, on an actual network, large ISPs with multiple ASes can use carefully constructed routes to bypass ROA and ASPA authentication to attack the target network. This document defines an region-based authentication method for large ISPs with many ASes to prevent traffic hijacking within ISPs. "RSVP for TSN Networks", Dirk Trossen, Juergen Schmitt, 2022-07-07, This document provides a solution for control plane signaling by virtue of proposing changes to RSVP signaling with deterministic services at the underlying TSN enabled layer. The solution covers distributed, centralized, and hybrid signaling scenarios in the TSN and SDN domain. The proposed changes to RSVP IntServ, called RSVP TSN in the remainder of this document, provide a better integration with Layer 2 technologies for resource reservation, for which we outline example API specifications for the realization of RSVP TSN. "Generic Metric for the AIGP attribute", Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, 2022-07-11, 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. "MPLS Label Stacks in Tunnel Encapsulation Attribute", Zhaohui Zhang, Susan Hares, 2022-10-11, RFC 9012 defines an MPLS Label Stack sub-TLV for Tunnel Encapsulation Attribute, and specifies that it is to be pushed BEFORE other labels. This document clarifies the use case for that, defines a new Tunnel Label Stack sub-TLV for a label stack to be pushed AFTER other labels (e.g., the label embedded in the NLRI for a labeled address family, and/or the stack in an MPLS Label Stack sub-TLV), and defines two new Segment sub-TLVs to encode a segment list in a compact format. "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil Cook, Mohamed Boucadair, 2022-09-21, DNS filtering is widely deployed for network security, but filtered DNS responses lack information for the end user to understand the reason for the filtering. Existing mechanisms to provide detail to end users cause harm especially if the blocked DNS response is to an HTTPS website. This document updates the EXTRA-TEXT field of Extended DNS Error to provide details on the DNS filtering. This information can be parsed by the client and displayed, logged, or used for other purposes. This document updates RFC 8914. "Transmission of SCHC-compressed packets over IEEE 802.15.4 networks", Carles Gomez, Ana Minaburo, 2022-11-08, 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. "Security for the NFSv4 Protocols", David Noveck, 2022-09-26, 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. 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 description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881. "EVPN multi-homing support for L3 services", Michael MacKenzie, Patrice Brissette, Satoru Matsushima, Wen Lin, Jorge Rabadan, 2022-10-24, This document brings the machinery and solution providing higher network availability and load balancing benefits of EVPN Multi- Chassis Link Aggregation Group (MC-LAG) to various L3 services delivered by EVPN. "Encoding Network Slice Identification for SRv6", Weiqiang Cheng, Guangming Yang, Changwang Lin, Liyan Gong, Shay Zadok, Mingyu Wu, xuewei wang, 2022-10-20, 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, 2022-10-24, This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. "OSCORE-capable Proxies", Marco Tiloca, Rikard Hoeglund, 2022-09-23, 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 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 with intermediaries is used. "Service Function Chaining (SFC) Parallelism and Diversions", Donald Eastlake, 2022-11-27, 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 and to easily splice in additional service functions or splice service functions out of a service chain. This document provides use cases for these requirements and extensions to SFC to support them. "IKEv2 support for per-queue Child SAs", Antony Antony, Tobias Brunner, Steffen Klassert, Paul Wouters, 2022-11-08, This document defines three Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) indicating support for the negotiation of multiple identical Child SAs to optimize performance. The CPU_QUEUES notification indicates support for multiple queues or CPUs. The CPU_QUEUE_INFO notification is used to confirm and optionally convey information about the specific queue. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular Traffic Selector set. Using multiple identical Child SAs has the benefit that each stream has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their crypto state or disable their packet replay protection. "Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment", XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, 2022-07-01, Neighbor Discovery (ND) is the 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 issues may happen in various scenarios. The issues and solutions are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions, and how the various solutions fit together. Therefore, deployment guidelines are needed. 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 solving ND issues. Four isolation methods are proposed and their applicability is discussed. Guidelines are then described for selecting a suitable isolation method based on the deployment scenario. "Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS Networks", Rakesh Gandhi, Patrice Brissette, Eddie Leyton, 2022-07-11, Pseudowires (PWs) 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 in MPLS networks. The procedure uses PW Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without an IP/UDP header. "Concise Reference Integrity Manifest", Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan, 2022-07-11, 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 Concise Reference Integrity Manifests (CoRIM) that represent Endorsements and Reference Values in CBOR format. Composite devices or systems are represented by a collection of Concise Module Identifiers (CoMID) and Concise Software Identifiers (CoSWID) bundled in a CoRIM document. "Security and Privacy Considerations for Multicast Transports", Kyle Rose, Jake Holland, 2022-07-11, 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. "Composite Public and Private Keys For Use In Internet PKI", Mike Ounsworth, Massimiliano Pala, Jan Klaussner, 2022-10-22, The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementors may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structures CompositePublicKey and CompositePrivateKey, which are sequences of the respective structure for each component algorithm. The generic composite variant is defined which allows arbitrary combinations of key types to be placed in the CompositePublicKey and CompositePrivateKey structures without needing the combination to be pre-registered or pre-agreed. The explicit variant is alxso defined which allows for a set of algorithm identifier OIDs to be registered together as an explicit composite algorithm and assigned an OID. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite signatures and encryption, such as [I-D.ounsworth-pq-composite-sigs] and [I-D.ounsworth-pq-composite-kem]. "Interconnecting Limited Domains Based on Declared Communication Requirements", Carsten Bormann, 2022-07-11, "Limited Domains" are parts of an internet that may have notable differences or are just convenient to separate from the general Internet and can be delimited from that and from other Limited Domains by a defined boundary (the "border"). This memo focuses on the case where the nodes inside the Limited Domain want to interact with nodes on (or reachable via) the general Internet, but need some assistance at the border that is cognizant about the specific properties of the nodes in the Limited Domain. Self-Descriptions can provide the information needed for this assistance. "Building blocks for Network Slice Realization in Segment Routing Network", Zafar Ali, Clarence Filsfils, Pablo Camarillo, Dan Voyer, Satoru Matsushima, Reza Rokui, Amit Dhamija, Praveen Maheshwari, 2022-09-07, This document describes how to realize the IETF network slice using the Segment Routing based technology. It explains how the building blocks specified for the Segment Routing can be used for this purpose. "Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet, Michael Behringer, 2022-10-24, 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. "A summary of security-enabling technologies for IoT devices", Brendan Moran, 2022-10-21, 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. "HTTP Datagrams, UDP Proxying, and Extensible Prioritization", Lucas Pardue, 2022-07-25, Application protocols using the QUIC transport protocol rely on streams, and optionally the unreliable datagram extension, to carry application data. Streams and datagrams can be multiplexed in single connections but QUIC does not define an interoperable prioritization scheme or signaling mechanism. The HTTP Extensible Prioritization scheme describes an application-level scheme for the prioritization of streams in HTTP/2 and HTTP/3. This document defines how Extensible Priorities can be augmented to apply to the multiplexing of HTTP datagram flows with other flows or streams. "Transient Hiding of Hop-by-Hop Options", Donald Eastlake, 2022-07-08, There are increasing requests for a variety IPv6 hop-by-hop options but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options are commonly 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. "MPLS Data Plane Encapsulation for In-situ OAM Data", Rakesh Gandhi, Zafar Ali, Frank Brockners, Bin Wen, Bruno Decraene, Haoyu Song, Voitek Kozak, 2022-11-05, 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 how IOAM data fields are transported with MPLS data plane encapsulation using MPLS Network Action (MNA) and follows the MNA framework defined in draft-ietf-mpls-mna-fwk. "Automatic Replication of DNS-SD Service Registration Protocol Zones", Ted Lemon, Abtin Keshavarzian, Jonathan Hui, 2022-07-11, 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. "YANG Data Model for Bidirectional Forwarding Detection (BFD) Hardware Offloaded Session", VELUCHAMY Rajaguru, 2022-08-23, This document defines a extension YANG data model that can be used to manage Hardware Offloaded Bidirectional Forwarding Detection (BFD). This document specially talks about BFD sessions that are offloaded to hardware. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "Advertisement of Stub Link Attributes", Aijun Wang, Zhibo Hu, Acee Lindem, Gyan Mishra, Jinsong Sun, 2022-10-20, 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, 2022-08-04, 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. "Mathematical Mesh 3.0 Part VI: Reliable User Datagram", Phillip Hallam-Baker, 2022-10-23, A presentation layer suitable for use in conjunction with HTTP and UDP transports is described. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . "Knowledge Transmission Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel", Kun Li, Hua-chun Zhou, Zhe Tu, Feiyang Liu, Weilin Wang, 2022-08-26, DOTS Knowledge Trans August 2022 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, 2022-10-21, 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]. 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. "LISP for Computing-Aware Networking", Sun Kj, Younghan Kim, 2022-11-05, When a service has been distributed over many locations in the network, providing service by utilizing computing resources hosted in various servers is required to consider supporting delay-sensitive service and optimizing network loads. For that reason, Computing- Aware Networking (CAN) is a new routing approach to balance services using service-specific metrics instead of simply dispatching the service request in a static way or optimizing solely connectivity metrics [draft-liu-can-ps-usecases]. Currently, CAN solutions are discussed with both existing technologies (e.g., DNS, L7 Load Balancer, etc.) and a new approach. In this document, it describes the LISP-based CAN approach and related standard works to meet requirements. "The Application Specific Link Attribute (ASLA) Any Application Bit", Shraddha Hegde, Ron Bonica, Chris Bowers, Robert Raszuk, Zhenbin Li, Dan Voyer, 2022-07-11, RFC 8919 and RFC 8920 define Application Specific Link Attributes (ASLA). Each ASLA includes an Application Identifier Bit Mask. The Application Identifier Bit Mask includes a Standard Application Bit Mask (SABM) and a User Defined Application Bit Mask (UDABM). The SABM and UDABM determine which applications can use the ASLA as an input. This document introduces a new bit to the Standard Application Identifier Bit Mask. This bit is called the Any Application Bit (i.e., the A-bit). If the A-bit is set, the link attribute can be used by any application. This includes currently defined applications as well as applications to be defined in the future. "Defreezing Optimization post EVPN Mac Dampening", DIKSHIT Saumya, Vinayak Joshi, Swathi Shankar, 2022-08-04, 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. "Data Model for Lifecycle Management and Operations", Marisol Palmero, Frank Brockners, Sudhendu Kumar, Shwetha Bhandari, Camilo Cardona, Diego Lopez, 2022-10-24, This document motivates and specifies a data model for lifecycle management and operations. It describes the motivation and requirements to collect asset-centric metrics including but not limited to asset adoption and usability, licensing, supported features and capabilities, enabled features and capabilities, etc.; with the primary objective to measure and improve the overall user experience along the lifecycle journey, from technical requirements and technology selection through advocacy and renewal, including the end of life of an asset. "Enhanced Performance Measurement Using Simple TWAMP in Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Navin Vaghamshi, Moses Nagarajah, Richard Foote, Mach Chen, Amit Dhamija, 2022-08-12, 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 defines procedure for Enhanced Performance Measurement of end-to-end SR paths including SR Policies for both SR-MPLS and SRv6 data planes using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762. The procedure allows to improve the scale for number of sessions and failure detection interval. "Antitrust Guidelines for IETF Particiants", Joel Halpern, Brad Biddle, Jay Daley, 2022-10-22, This document provides guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. "hashlookup format", Alexandre Dulaunoy, Jean-Louis Huynen, 2022-06-23, This document describes the hashlookup output format used to express meta information of hash values seen in databases of known files. The output description includes a common semantic. The hashlookup format is used by public and private digital forensics investigations services. "All PEs as DF", DIKSHIT Saumya, Vinayak Joshi, 2022-08-04, 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. "Reputation Verified Selection of Upstream Encrypted Resolvers", Benjamin Schwartz, Chris Box, 2022-07-08, This draft describes an extension to the Discovery of Designated Resolvers (DDR) standard, enabling use of encrypted DNS in the presence of legacy DNS forwarders. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/ddr-forwarders. "Extending ICMP for IP-related Information Validation", Liu Yao, 2022-06-06, This document introduces the mechanism to verify the data plane against the control plane in IPv6/SRv6 networks by extending ICMP messages. "Secure Vector Routing (SVR)", Abilash Menon, Patrick MeLampy, Michael Baj, Patrick Timmons, Hadriel Kaplan, 2022-09-20, 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. "Additional block types for PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson, 2022-07-29, This document contains a number of extensions to the PCAPng file format which are outside of the IETF networking mandate. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the OPSAWG 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/pcapng/pcapng. "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. "Application-Oriented Literals in CBOR Extended Diagnostic Notation", Carsten Bormann, 2022-10-24, The Concise Binary Object Representation, CBOR (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 the use of CBOR diagnostic notation with CoRAL and Constrained Resource Identifiers (draft-ietf-core-coral, draft-ietf-core-href). "YANG model for Data Export over IP Flow Information Export (IPFIX) Protocol", Anand Arokiaraj, Marta Seda, 2022-08-29, This document defines a YANG model for data export via the IP Flow Information Export (IPFIX) protocol. The YANG model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, Alex Brotman, 2022-10-09, 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. "Requirements for Large-Scale Deterministic Networks", Peng Liu, Yizhou Li, Toerless Eckert, Quan Xiong, Jeong-dong Ryoo, zhushiyin, Xuesong Geng, 2022-10-20, Aiming at the large-scale deterministic network with long hops, large per-hop time variation, great number of flows and/or multiple domains without the same time source, this document describes the technical and operational requirements when the different deterministic levels of applications co-exist and are transported. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. "UDP-based Generic Multi-Access (GMA) Control Protocol", Jing Zhu, Menglei Zhang, 2022-10-03, A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity 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 control protocol to manage traffic steering, splitting, and duplicating across multiple connections. The solution has been developed by the authors based on their experiences in multiple standards bodies including the 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 in order to experiment with the protocol. "VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong, 2022-10-09, 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). "Illustrations for Compressed SRv6 Segment List Encoding in SRH", Francois Clad, Darren Dukes, 2022-10-24, This document provides illustrations for compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). "Scalability of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse, 2022-10-23, 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. "Extensions to the Access Control Lists (ACLs) YANG Model", Oscar de Dios, Samier Barguil, Mohamed Boucadair, 2022-10-24, 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. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Modeling Working Group mailing list (netmod@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netmod/. Source for this draft and an issue tracker can be found at https://github.com/oscargdd/draft-dbb-netmod-enhanced-acl. "A registry/registrar blockchain architecture for domain name registration data access protocol", Yu Zeng, Man Zhang, Wei Wang, 2022-06-26, This document defines a registry/registrar blockchain architecture for domain name registration data access protocol. "The Need for New Authentication Methods for Internet of Things", Dirk Von Hugo, Behcet Sarikaya, 2022-11-06, In framework of future 6G the need for easy and secure connectivity between a great amount of small devices as sensors and household appliances will be essential. Such massive Internet of Things (mIoT) requires authentication methods which are reliable also in case of vulnerable wireless links and work for simple cheap (dumb) devices. Aim of this document is to lay ground for the need for new authentication models and admission methods in the framework of devices (e.g., machines in IoT communication) within a (wireless or wireline-based) network. Simple devices may only have a minimum amount of physical interfaces available. As an example for establishing an out-of-band channel for exchange of authentication material radio sensing technology may serve. This is currently under investigation for Wireless LAN and upcoming cellular radio at both IEEE and 3GPP. "Advertising S-BFD Discriminators in BGP", Haibo Wang, Jie Dong, Greg Mirsky, Yang Huang, 2022-12-03, Seamless Bidirectional Forwarding Detection (S-BFD) is a simplified BFD mechanism. It eliminates most negotiation aspects and provides advantages such as fast configuration injection. S-BFD is especially useful in multi-homing PE scenarios and reduces resource overheads on the dual-homing PEs. Although S-BFD is simpler than BFD, a large number of manual configurations are required when there are a large number of PEs. This document provides the mechanism of distributing S-BFD discriminators with VPN service routes, which simplifies S-BFD deployment for VPN services. "Updated Rules for PCEP Object Ordering", Dhruv Dhody, 2022-07-09, The Path Computation Element (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. "Satellite Semantic Addressing for Satellite Constellation", Lin Han, Richard Li, Alvaro Retana, chenmeiling, Ning Wang, 2022-09-04, This document presents a semantic addressing method for satellites in satellite constellation connecting with Internet. The satellite semantic address can indicate the relative position of satellites in a constellation. The address can be used with traditional IP address or MAC address or used independently for IP routing and switching. "Unicast Use of the Formerly Reserved 240/4", Seth Schoen, John Gilmore, David Taht, 2022-07-06, 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, 2022-07-06, The adoption of artificial intelligence (AI) in network management (NM) solutions is becoming a reality. It is mainly supported by the need to resolve complex problems arisen from the acceptance of SDN/ NFV technologies as well as network slicing. Thus, the AINEMA framework, as discussed in this document, is required to keep focus and organize the efforts on applying AI to NM. This is enlarged by the inclusion of external events in NM operations as well as the consideration of a full intelligence process instead of simple AI- based guesses. Such process will be highly based in reasoning and formal and target-based intelligence analysis and decision. This will allow computer and network system infrastructures to grow in complexity. The same applies to user demands. The construction and maintenance of AINEMA requires a comprehensive inclusion of several mechanisms. For instance, although there has been a lot of effort to make Machine Learning (ML) solutions reliable and acceptable, other mechanisms have been forgotten. It is the particular case of reasoning, which is the key within AINEMA. It will provide enormous benefits to NM solutions by, for example, inferring new knowledge and applying different kind of rules (e.g. logical) to choose from several actions. While ML solutions work with data, so their only requirement from the network infrastructure is data retrieval, AINEMA will work in collaboration to the network it is managing. This makes the challenges arisen from intelligent reasoning essential for the evolution of NM. They will be addressed within the context of AINEMA. "Innovation in Internet Routing and Addressing", Luigi Iannone, 2022-10-24, Despite the stability of the Internet technology, tremendous advances and important innovation are always happening. In particular, routing and addressing have profoundly changed during the years, with interesting research still ongoing and engineers willing to be hear about recent advance that may solve their operational problems. However, researchers and engineers lack a dedicated forum where they can meet and interact to discuss about routing and addressing. This document advocates the creation of such forum, to bring together these communities (researchers and engineers) and offer a dedicated venue. "Unicast Use of the Lowest Address in an IPv4 Subnet", Seth Schoen, John Gilmore, David Taht, Michael Karels, 2022-12-01, 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. "Secure Credential Transfer", Dmitry Vinokurov, Matt Byington, Matthias Lerch, Alex Pelletier, Nick Sha, 2022-07-08, This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information. "Constrained Application Protocol (CoAP) Performance Measurement Option", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fabio Bulgarella, Massimo Nilo, 2022-10-24, 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 on- path. "BGP-SPF Flooding Reduction", Huaimo Chen, Gyan Mishra, Aijun Wang, Yisong Liu, Haibo Wang, Yanhe Fan, 2022-11-15, 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) RR", Ted Lemon, Liang Qin, 2022-07-11, 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 DNS RR 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, 2022-11-07, 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, 2022-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 fowarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detcetion 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 an anycast RPF checking mechanism in dataplane as an instead. "Support for Virtual Transport Network (VTN) in the Path Computation Element Communication Protocol (PCEP)", Jie Dong, Sheng Fang, Liuyan Han, Minxue Wang, 2022-07-11, With the introduction and evolvement of 5G and other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional Virtual Private Networks (VPNs). Such kind of network service is called enhanced VPNs (VPN+). The typical application of VPN+ is to provide network slice services. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. Then traffic flows of the VPN+ service can be steered onto the TE paths within the VTN. The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-protocol Label Switching (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks. This document specifies the extensions to PCE communication Protocol (PCEP) to carry VTN information in the PCEP messages. The extensions in this document can be used in the basic PCE computation, the stateful PCE and the PCE-initiated LSP mechanisms to indicate path computation, path status report and path initialization within a specific VTN. "Traffic Mapping YANG model for Traffic Engineering (TE)", Dhruv Dhody, 2022-10-24, 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, 2022-07-11, 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. "Application-aware Networking (APN) Header", Zhenbin Li, Shuping Peng, Shuai Zhang, 2022-10-09, This document defines the application-aware networking (APN) header which can be used in a variety of data planes. "IPv6 Query for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, 2022-09-05, This document describes the IPv6 Node IOAM Information Query functionality, which uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. This document updates RFCs 4620 and 4884. "Comparing One-way Delays in Multipath", Jiao Kang, liangqiandeng, Shangling Deng, Peng Liu, 2022-06-16, This document provides a solution for comparing one-way delays in multipath quic. In this solution, through message interaction between data receiver and data sender, the data sender can obtain delay rankings of multiple specified uniflows, providing reference for sending data packets. "Signal Degrade Indication in BFD", Liuyan Han, Minxue Wang, Fan Yang, 2022-07-07, To satisfy the requirements of signal degrade indication described in [I-D.yang-mpls-ps-sdi-sr], this document illustrates the extension of BFD protocol to support signal degrade indication. "A YANG Model for Application-aware Networking (APN)", Shuping Peng, Zhenbin Li, 2022-11-05, 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). "RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6", Yisong Liu, Jingrong Xie, Xuesong Geng, Mengxiao Chen, 2022-07-10, This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. "Source Segment for Multicast Source Routing over IPv6", Jingrong Xie, Xuesong Geng, Yisong Liu, Mengxiao Chen, 2022-07-10, This document defines the general concept of source segment which is used as the IPv6 source address in an IPv6 packet. Source segment for multicast service is introduced in this document. "IPv6 Multicast Source Routing Traffic Engineering", Xuesong Geng, Zhenbin Li, Jingrong Xie, 2022-10-24, This document defines 2 new types of segment: End.RL and End.RL.X , and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions. "Flow Measurement in IPv6 Network", Haojie Wang, Yisong Liu, Changwang Lin, Xiao Min, 2022-10-11, This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. "A Data Manifest for Contextualized Telemetry Data", Benoit Claise, Jean Quilbeuf, Diego Lopez, Ignacio Martinez-Casanueva, Thomas Graf, 2022-10-24, Most network equipment feature telemetry as a mean to monitoring their status. Several protocols exist to this end, for example, the model-driven telemetry governed by YANG models. Some of these protocols provide the data itself, without any contextual information about the collection method. This can render the data unusable if that context is lost, for instance when the data is stored without the relevant information. This document proposes the Data Manifest, which is composed of two YANG data models, namely, the Platform Manifest and the Data Collection Manifest, to store contextual information along with the collected data, in order to keep the collected data exploitable in the future. "Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design", James Gruessing, Spencer Dawkins, 2022-11-07, 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. "Dissemination of BGP Flow Specification Rules for APN", Shuping Peng, Zhenbin Li, Sheng Fang, Yong Cui, 2022-11-05, 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. "Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks", Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin, 2022-10-07, 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, 2022-07-11, 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. "Problems and Requirements of Addressing in Integrated Space-Terrestrial Network", Yuanjie Li, Hewu Li, Lixin Liu, Qian Wu, Jun Liu, 2022-10-21, This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. "Problems and Requirements of Evaluation Methodology for Integrated Space and Terrestrial Networks", Zeqi Lai, Hewu Li, Yangtao Deng, Qian Wu, Jun Liu, 2022-10-24, With the rapid evolution of the aerospace industry, many "NewSpace" upstarts are actively deploying their mega-constellations in low earth orbits (LEO) and building integrated space and terrestrial networks (ISTN), promising to provide pervasive, low-latency, and high-throughput Internet service globally. Due to the high manufacturing, launching, and updating cost of LEO mega- constellations, it is expected that ISTNs can be well designed and evaluated before the launch of satellites. However, the progress of designing, assessing, and understanding new network functionalities and protocols for futuristic ISTNs faces a substantial obstacle: lack of standardized evaluation methodology with acceptable realism (e.g. can involve the unique dynamic behaviors of ISTNs), flexibility, and cost. This memo first reviews the unique characteristics of LEO mega-constellations. Further, it analyzes the limitation of existing evaluation and analysis methodologies under ISTN environments. Finally, it outlines the key requirements of future evaluation methodology tailored for ISTNs. "Preferred Path Routing Framework", Stewart Bryant, Uma Chunduri, Alexander Clemm, 2022-11-07, Capacity demands, Traffic Engineering (TE) and determinism are some of key requirements for various cellular, edge and industrial deployments. These deployments span from many underlying data pane technologies including native IPv4, native IPv6 along with MPLS and Segment Routing (SR). This document provides a framework for Preferred Path Routing (PPR). PPR is a method of providing path based dynamic routing for a number of packet types including IPv4, IPv6 and MPLS. This seamlessly works with a controller plane which holds both complete network view of operator policies, while distributed control plane providing self- healing benefits in a near-real time fashion. PPR builds on existing encapsulations at the edge nodes to add path identity to the packet. This reduces the per packet overhead required for path steering and therefore has a smaller impact on both packet MTU, data plane processing and overall goodput for small payload packets, while extending path steering benefits to any existing data plane. A number of extensions that allow expansion of use beyond simple point-to-point-paths are also described in this memo. "Path Computation Element Protocol(PCEP) Extension for Color", Balaji Rajagopalan, Vishnu Beeram, Shaofu Peng, Quan Xiong, Mike Koldychev, Gyan Mishra, 2022-07-06, Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g. low latency). This document specifies an extension to Path Computation Element Protocol (PCEP) to carry the color attribute. "Segment Routing IPv6 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, 2022-10-24, This document defines the Segment Routing IPv6 Mobile User Plane (SRv6 MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. Mobile services are deployed over several parts of IP networks. A Segment Routing over IPv6 (SRv6) network can accommodate all, or part of those networks thanks to the large address space of IPv6 and the network programming capability described in [RFC8986]. Segment Routing IPv6 Mobile User Plane Architecture can incorporate existing session based mobile networks. By leveraging SRv6 network programmability, mobile user plane can be integrated into the SRv6 data plane. In that routing paradigm, session information between the entities of the mobile user plane is turned to routing information. "EVPN Fast Reroute", Luc Burdet, Patrice Brissette, Takuya Miyasaka, Jorge Rabadan, 2022-10-23, 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, 2022-10-21, 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. "Considering ALTO as IETF Network Exposure Function", Luis Contreras, 2022-07-11, This document proposes ALTO as the means for exposure of underlay network capabilities for multiple overlays on top of the network. "IANA Registry for the First Nibble Following a Label Stack", Kireeti Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson, 2022-07-10, The goal of this memo is to create a new IANA registry (called the MPLS 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 makes processing MPLS packets easier and more robust. There is an important caveat on the use of this registry versus the IP version number registry. This memo, if published, would update [RFC4928] and [RFC8469]. "Data minimization", Jari Arkko, 2022-10-24, Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. Privacy has also been a key focus area, and understanding the privacy implications of new Internet technology is an important factor when IETF works on such technologies. This document highlights the need for a particular focus with respect to privacy. It is necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. It is important to consider the role of data passed to various parties - including the primary protocol participants - and balance the information given to them considering their roles and possible compromise of the information. "Semantic Definition Format (SDF): Mapping files", Carsten Bormann, Jan Romann, 2022-10-24, 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. 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. "PCEP Extension for NRP-ID", Quan Xiong, Shaofu Peng, Vishnu Beeram, Tarek Saad, 2022-07-06, This document proposes a set of extensions for PCEP to support the identifier of Network Resource Partition (NRP-ID) as the constraint of network slicing during path computation. "Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP", Changwang Lin, Mengxiao Chen, Hao Li, Ruixue Wang, Fengwei Qin, Qi Zhang, 2022-11-24, 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. "Unicast Use of the Formerly Reserved 0/8", Seth Schoen, John Gilmore, David Taht, 2022-07-06, 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, 2022-08-29, This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. "NAT64/DNS64 detection via SRV Records", Martin Hunek, 2022-06-12, This document specifies how to discover the NAT64 pools in use and DNS servers providing DNS64 service to the local clients. The discovery made via SRV records allows the assignment of priorities to the NAT64 pools and DNS64 servers. It also allows clients to have different DNS providers than NAT64 providers while providing a secure way via DNSSEC validation of provided SRV records. This way, it provides DNS64 service regardless of DNS operator and DNS transport protocol. "Multi-cluster Edge System Architecture and Network Function Requirements", Dae Kim, Joo-Sang Youn, 2022-07-25, Artificial intelligence based IoT applications demand more massive computing resource through networks for the process of AI tasks. To support these applications, some new technologies based an edge computing and fog computing are emerging. Especially, the computation-intensive and latency-sensitive IoT applications such as augmented reality, virtual reality and AI based inference application is deployed with an edge computing and fog computing which are connected with cloud computing. Recently, cluster-based edge system is deployed to extend computation capacity of an edge server. The cluster-based edge system has the advantage that can enhace the resource scalability and availability in edge computing and fog computing. In this draft, we present cluster-based edge system architecture and multi-cluster edge network topology that consists of multi-cluster edge system and core cloud. Also, we define the network functions and network node to configurate and operate multi- cluster edge network collaboratively. "Control Plane of Inter-Domain Source Address Validation Architecture", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2022-11-20, 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 machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus on the control plane of the SAVA-X mechanism. "Data Plane of Inter-Domain Source Address Validation Architecture", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2022-11-20, 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 machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus 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, 2022-11-20, 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 machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus on the packet formats and processing flow of the SAVA-X mechanism. "IKEv2 Count Based SA Extension", Daniel Migault, Daiying Liu, Congjie Zhang, 2022-10-23, This document describes an IKEv2 extension that enables a more rational use of count based SA. This includes preventing the creation of redundant SAs resulting from simultaneous rekeys. "Open Ethics Transparency Protocol", Nikita Lukianets, 2022-11-21, 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. "Link-Local Next Hop Capability for BGP", Russ White, Jeff Tantsura, Donatas Abraitis, 2022-11-27, BGP, described in [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. Because of this, BGP does not recognize the use of IPv6 link-local addresses, as described in [RFC4291], as a valid next hop for forwarding purposes. However, BGP speakers are now often deployed on point-to-point links in networks where multihop reachability of any kind is not assumed or desired (all next hops are assumed to be the speaker reachable through a directly connected point-to-point link). This is common, for instance, in data center fabrics. In these situations, a global IPv6 address is not required for the advertisement of reachability information; in fact, providing global IPv6 addresses in these kinds of networks can be detrimental to Zero Touch Provisioning (ZTP). This draft standardizes the operation of BGP over a point-to-point link using link-local IPv6 addressing only. "Internet Consolidation: What can Standards Efforts Do?", Mark Nottingham, 2022-12-03, Despite the Internet being designed and operated as a decentralized network-of-networks, forces continuously emerge to encourage and sometimes enforce consolidation of power into few hands. This document offers a definition of consolidation and relates it to centralization, explains why they are undesirable, identifies forces that contribute to them, catalogues limitations of common approaches to decentralization, and explores what Internet standards efforts can do. "Deprecating the Use of Router Alert in LSP Ping", Kireeti Kompella, Ron Bonica, Greg Mirsky, 2022-11-11, LSP ping messages (RFC 8029) are encapsulated in IP headers that include a Router Alert Option (RAO). The rationale for including an RAO is questionable. Furthermore, RFC6398 identifies security vulnerabilities associated with the RAO. Therefore, this document removes the RAO from LSP ping message encapsulations. It updates RFCs 7506 and 8029. This document also recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. "IPlir network layer security protocol", Davletshina Alexandra, Urivskiy Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia, 2022-11-24, 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. "IP Parcels", Fred Templin, 2022-11-06, IP packets (both IPv4 and IPv6) contain a single unit of upper layer protocol data which becomes the retransmission unit in case of loss. Upper layer protocols including the Transmission Control Protocol (TCP) and transports over the User Datagram Protocol (UDP) prepare data units known as "segments", with traditional arrangements including a single segment per IP packet. This document presents a new construct known as the "IP Parcel" which permits a single packet to carry multiple upper layer protocol segments, essentially creating a "packet-of-packets". IP parcels provide an essential building block for improved performance and efficiency by encouraging larger Maximum Transmission Units (MTUs) in the Internet as discussed in this document. "Service Routing in Multi-access Edge Computing", Zongpeng Du, 2022-10-23, This document introduces a service routing mechanism in the scenario of Multi-access Edge Computing, in which the server's preferred address mechanism in QUIC can be used. "RIFT Auto-Flood Reflection", Jordan Head, Tony Przygienda, Colby Barth, 2022-10-24, This document specifies procedures where RIFT can automatically provision IS-IS Flood Reflection topologies by leveraging its native no-touch ZTP architecture. "Remote Procedure Call over QUIC Version 1", Benjamin Coddington, Scott Mayhew, Chuck Lever, 2022-07-05, This document specifies a protocol for conveying Remote Procedure (RPC) messages on QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. "Deadline Based Deterministic Forwarding", Shaofu Peng, Bin Tan, Peng Liu, 2022-10-22, This document describes a deterministic forwarding mechanism based on deadline. The mechanism enhances strict priority scheduling algorithm with dynamically adjusting the priority of the queue according to its deadline attribute. "Deadline Option", Shaofu Peng, Bin Tan, Peng Liu, 2022-07-11, This document introduces new IPv6 options for Hop-by-Hop Options header, to carry deadline related information for deterministic flows. "IGP Extensions for SR Network Resource Partition SIDs", Tarek Saad, Vishnu Beeram, Ran Chen, Shaofu Peng, Bin Wen, Daniele Ceccarelli, 2022-07-11, Segment Routing (SR) defines a set of topological "segments" within an IGP topology to enable steering over a specific SR path. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes extensions to the IS-IS and OSPF required to support the signaling of Resource Partition (NRP) segments that operate over SR-MPLS and SRv6 dataplanes. Multiple SR NRP segments can be associated with the same topological element to allow offering of different forwarding treatments (e.g. scheduling and drop policy) associated with each NRP. "IGP Flexible Algorithm with Deterministic Routing", Shaofu Peng, Tony Li, 2022-08-24, IGP Flexible Algorithm proposes a solution that allows IGPs to compute constraint based paths over the network and specifies a way of using Segment Routing (SR) Prefix-SIDs, SRv6 locators, or pure IP prefixes to steer packets along the constraint-based paths. This document describes how to compute deterministic delay paths within a Flex-Algorithm topology. "Use Cases of Computing-aware Service Function Chaining (SFC)", Shuai Zhang, Xia Chen, 2022-07-25, Multiple occurrences of the same service function(SF) can exist in the same administrative domain and each occurrence of SF is called SF instance. A Service Function Path(SFP) is determined by composing selected SF instances and overlay links. The SF instances are selected according to the computing power of SFs in addition to the network information and this is defined as the computing-aware SFC in this document. This document describes the use cases for computing-aware Service Function Chaining(SFC). "Multi-part TLVs in IS-IS", Parag Kaneriya, Tony Li, Tony Przygienda, Shraddha Hegde, Chris Bowers, Les Ginsberg, 2022-11-30, 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. "A YANG Data Model for Network Resource Partitions (NRPs)", Bo Wu, Dhruv Dhody, Mohamed Boucadair, Ying Cheng, Liyan Gong, 2022-09-25, This document defines a YANG data model of Network Resource Partition (NRP) for the NRP management operation. The model can be used for the realization of IETF Network Slice Services. "Continuing to Evolve Internet Routing Beyond 'Mere' Reachability", Dirk Trossen, Zhe Lou, Sheng Jiang, 2022-06-30, This document discusses the evolution of the Internet routing system beyond mere reachability. We observe, through examples of past development, that such evolution has been taking place to improve on capabilities of the Internet, deal with more complicated network deployments and cater to changing requirements by end users as well as novel and emerging applications. For achieving a routing system that serves more than a singular reachability purpose, more information is taken into account when performing the purpose-specific functions. Such extra information can be obtained by extending current routing protocols to exchange more information or by carrying that information within packets. This document is intended to seed discussions of how the observed evolution of the Internet's routing system can continue, what issues may occur when simply continuing the current approach for achieving routing beyond 'mere' reachability and what may be needed to address those issues. Ultimately, however, this document recognizes the positive impact that moving beyond reachability has brought to the Internet and will continue to do so. "Warp - Segmented Live Media Transport", Luke Curley, Kirill Pugin, Suhas Nandakumar, 2022-10-24, This document defines the core behavior for Warp, a segmented live media transport protocol over QUIC. Media is split into segments based on the underlying media encoding and transmitted independently over QUIC streams. QUIC streams are prioritized based on the delivery order, allowing less important segments to be starved or dropped during congestion. "RLB (Replication through Local Bitstring) Segment for Multicast Source Routing over IPv6", Xuesong Geng, Zhenbin Li, Jingrong Xie, 2022-10-24, 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. "YANG Extension and Metadata Annotation for Immutable Flag", Qiufang Ma, Qin WU, Balazs Lengyel, Hongwei Li, 2022-10-20, This document defines a YANG extension named "immutable" to indicate that specific "config true" data nodes are not allowed to be created/deleted/updated. To indicate that specific entries of a list/leaf-list node or instances inside list entries cannot be updated/deleted after initialization, a metadata annotation with the same name is also defined. Any data node or instance marked as immutable is read-only to the clients of YANG-driven management protocols, such as NETCONF, RESTCONF and other management operations (e.g., SNMP and CLI requests). This document aims to provide more visibility into immutability characteristic of particular schema or instance nodes by defining a standard mechanism to allow the server to document the existing immutable configuration data, while this doesn't mean attaching such restrictions is encouraged. "Amplification Attacks Using the Constrained Application Protocol (CoAP)", John Mattsson, Goeran Selander, Christian Amsuess, 2022-11-09, 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. "Suppressing CA Certificates in TLS 1.3", Martin Thomson, Panos Kampanakis, Cameron Bytheway, Bas Westerbaan, 2022-07-08, A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. "Impact of DLTs on Provider Networks", Dirk Trossen, David Guzman, Mike McBride, Xinxin Fan, 2022-08-30, 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, 2022-08-15, 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. "L3ND Upper-Layer Protocol Configuration", Randy Bush, Keyur Patel, 2022-10-01, This document adds PDUs to the Layer-3 Neighbor Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. "Layer-3 Neighbor Discovery", Randy Bush, Russ Housley, Rob Austein, Susan Hares, Keyur Patel, 2022-10-01, Data Centers where the topology is BGP-based need to discover neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 Neighbor Discovery protocol identifies BGP neighbor candidates. "Standard PKC Test Keys", Peter Gutmann, Corey Bonnell, 2022-11-08, This document provides a set of standard PKC test keys that may be used wherever pre-generated keys and associated operations like digitial signatures are required. Like the EICAR virus test and GTUBE spam test files, these publicly-known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them. "PCEP Extension for DetNet Bounded Latency", Quan Xiong, Peng Liu, 2022-10-09, In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions to PCEP to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in DetNet service. "Enhanced Port Forwarding functions with CGNAT", Louis Chan, 2022-08-21, There is a need for peer-to-peer (P2P) communication under the use of CGNAT in service providers. With the combination of home gateway, this becomes NAT444. In RFC5128, methods of using UDP hole punching solves the problem partially when EIM (Endpoint-Independent Mapping) is supported in NAT device in the path, and there exists a common rendezvous server. The success rate of UDP hole punching is high, but not TCP hole punching in practical world. Also, the P2P solution requires a common server in the public internet to exchange the IP and port information. In this draft, a method is described to achieve incoming TCP or UDP session without a common rendezvous server in NAT444 situation. "Private Line Emulation over Packet Switched Networks", Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Luca Chiesa, Nagendra Nainar, Carlos Pignataro, Gerald Smallegange, Chris Brown, Faisal Dada, 2022-08-19, 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. "IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension", Daniel Migault, Daiying Liu, Renwang Liu, Congjie Zhang, 2022-11-20, This document considers a ingress and an egress security gateway connected over a IPv4 network. The Tunnel Link Packet have their Don't Fragment (DF) set to 0. This document defines the IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension which enables the egress security gateway to notify the ingress security gateway that Mid-tunnel Fragmentation is observed with the value of the Link Maximum Atomic Packet. The ingress security gateway is expected to take action as to avoid the egress security gateway to perform costly reassemble operation. The ingress security gateway is expected to either perform (when possible) Inner Fragmentation of to update Tunnel MTU. "Using CDDL for CSVs", Carsten Bormann, 2022-08-29, 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. "DetNet Data Plane Enhancements for Large-Scale Deterministic Networks", Quan Xiong, Zongpeng Du, Junfeng Zhao, Dong Yang, 2022-10-24, 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 analyzes the gaps of the existing technologies especially applying the DetNet data plane as per RFC8938 and proposes the enhancement of packet treatment to support the functions and metadata for enhanced DetNet data plane. It describes related enhanced controller plane considerations as well. "One-way Delay Measurement Based on Reference Delay", Hongwei Yang, Kehan Yao, Jean-Yves Le Boudec, 2022-06-29, The end-to-end network one-way delay is an important performance metric in the 5G network. For realizing the accurate one-way delay measurement, existing methods requires the end-to-end deployment of accurate clock synchronization mechanism, such as PTP or GPS, which results in relatively high deployment cost. Another method can derive the one-way delay from the round-trip delay. In this case, since the delay of the downlink and uplink of the 5G network may be asymmetric, the measurement accuracy is relatively low. Hence, this document introduces a method to measure the end-to-end network one- way delay based on a reference delay guaranteed by deterministic networking without clock synchronization. "Considerations for Protection of SRv6 Networks", Yisong Liu, Weiqiang Cheng, Changwang Lin, Xuesong Geng, Liu Yao, 2022-07-06, This document describes the considerations for protection of SRv6 network. "Extensible Provisioning Protocol (EPP) Mapping over HTTP", Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Jan Romanowski, Marcin Machnio, 2022-06-13, This document describes how the Extensible Provisioning Protocol (EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This mapping requires the use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. "S-BFD Path Consistency over SRv6", Changwang Lin, Weiqiang Cheng, Jiang Wenying, 2022-07-10, Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. 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 SRv6, when a headend use S-BFD to monitor the segment list/CPath of SRv6 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 of S-BFD consistent when detecting SRv6 Policy. "Everything over CoAP", Christian Amsuess, 2022-07-11, 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. "Benchmarking Methodology for MPLS Segment Routing", Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, 2022-10-24, This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over MPLS (SR-MPLS). It builds upon [RFC2544], [RFC5695] and [RFC8402]. "Benchmarking Methodology for IPv6 Segment Routing", Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, 2022-10-24, This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6). It builds upon [RFC2544], [RFC5180], [RFC5695] and [RFC8402]. "SRPM Path Consistency over SRv6", sijun weng, Weiqiang Cheng, Changwang Lin, Xiao Min, 2022-10-20, 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. "Computing Resource Representation in Computing Aware Networking", Zongpeng Du, Yuexia Fu, 2022-07-11, This document introduces the way of encoding service-specific information and the way of signaling it in the network. "IETF Network Slice Service Mapping YANG Model", Dhruv Dhody, Bo Wu, 2022-10-24, This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resource and TE/VPN models. "Inband Flow Learning Framework", Liuyan Han, Minxue Wang, Fan Yang, 2022-07-11, To deploy the inband performance measurement and flow information telemetry on live traffic, this document proposes a framework of an inband and flow based flow information learning mechanism called Inband Flow Learning (IFL). This document also provides different deployment approaches and considerations in practical network deployment. "A Framework for QoS-Enabled Semantic Routing in Industrial Networks", Paolo Bellavista, Luca Foschini, Lorenzo Patera, Mattia Fogli, Carlo Giannelli, Cesare Stefanelli, Zhe Lou, 2022-08-31, Industrial networks pose unique challenges in realizing a communication substrate on the shop floor. Such challenges are due to strict Quality of Service (QoS) requirements, a wide range of protocols for data exchange, and highly heterogeneous network infrastructures. In this regard, this document proposes a framework for QoS-enabled semantic routing in industrial networks. Such a framework aims at providing loosely-coupled, asynchronous communications, fine-grained traffic management (delivery semantics and flow priorities), and in-network traffic optimization. "pretty Easy privacy (pEp): Privacy by Default", Volker Birk, Hernani Marques, Bernie Hoeneisen, 2022-10-21, The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer- to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. "BGP SR Policy Extensions for Network Resource Partition", Jie Dong, Zhibo Hu, Ran Pang, 2022-07-11, 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 collection of network resources allocated in the network which can be used to support one or a group of IETF 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. "Advertisement of Dedicated Metric for Flexible Algorithm in IGP", Changwang Lin, Mengxiao Chen, Weiqiang Cheng, Liyan Gong, 2022-08-30, This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. "Framework For Internet Basic Behavior Measurement Metrics System", Wei Ding, 2022-10-12, This document provides a definition of Internet Basic Behavior Measurement(IBBM) based on the Internet architecture and describes in detail the specifications to be followed for the measurement metrics and measurement activities under IBBM, which are given in the form of elements. The main purpose of this document is to standardize the accurate meaning and expression of metrics obtained based on Internet behavioral measurement activities, to improve the use efficiency and worth of the measurement results. "BGP SPF for Network Resource Partitions", Jie Dong, Zhenbin Li, Haibo Wang, 2022-10-16, 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. In the context of network slicing, a VTN can be instantiated as a Network Resource Partition (NRP). 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. "dry-run DNSSEC", Yorgos Thessalonikefs, Willem Toorop, Roy Arends, 2022-07-11, This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing a new DS Type Digest Algorithm that signals validating resolvers that dry-run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of a dry-run DS. A further option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. "Path Tracing in SRv6 networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike Valentine, Amit Dhamija, 2022-08-16, 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. "Just Another Measurement of Extension header Survivability (JAMES)", Eric Vyncke, Raphael Leas, Justin Iurman, 2022-07-11, In 2016, RFC7872 has measured the drop of packets with IPv6 extension headers. This document presents a slightly different methodology with more recent results. It is still work in progress. "Game State over Real Time Protocol", Cullen Jennings, Rich Logan, 2022-10-24, This specification defines an Real Time Protocol (RTP) payload to send game moves and the state of game objects over RTP. This is useful for games as well collaboration systems that use augment or virtual reality. RTP provide a way to synchronize game state between players with robust technique for recovery from network packet loss while still having low latency. "An Alt-Svc Parameter and SvcParamKey for QUIC Versions", Martin Duke, Lucas Pardue, 2022-10-21, HTTP Alternative Services (Alt-Svc) describes how one origin's resource can be accessed via a different protocol/host/port combination. Alternatives are advertised by servers using the Alt- Svc header field or the ALTSVC frame. This includes a protocol name, which reuses Application Layer Protocol Negotiation (ALPN) codepoints. The "h3" codepoint indicates the availability of HTTP/3. A client that uses such an alternative first makes a QUIC connection. However, without a priori knowledge of which QUIC version to use, clients might incur a round-trip latency penalty to complete QUIC version negotiation, or forfeit desirable properties of a QUIC version. This document specifies a new Alt-Svc parameter that specifies alternative supported QUIC versions, which substantially reduces the chance of this penalty. Similarly, clients can retrieve additional instructions about access to services or resources via DNS SVCB and HTTP Resource Records. This document also defines a new SvcParamKey for these Resource Records, which specifies the specific QUIC versions in use. "BIER-TE Encapsulation with Multiple BitStrings", Huaimo Chen, Mike McBride, Ran Chen, Gyan Mishra, Aijun Wang, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-09-04, This document describes a "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) header, two levels of Bit Index Forwarding Tables (BIFTs) and a forwarding procedure for efficiently processing BIER-TE packets with the header. For a multicast packet with an explicit point-to-multipoint (P2MP) path, which has multiple BitStrings, the packet with the header containing the BitStrings is replicated and forwarded statelessly along the path. "QuicR - Media Delivery Protocol over QUIC", Cullen Jennings, Suhas Nandakumar, 2022-07-11, This specification outlines the design for a media delivery protocol over QUIC. It aims at supporting multiple application classes with varying latency requirements including ultra low latency applications such as interactive communication and gaming. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays in the cloud. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments. "QuicR - Media Delivery Protocol over QUIC", Cullen Jennings, Suhas Nandakumar, Christian Huitema, 2022-07-11, Recently new use cases have emerged requiring higher scalability of media delivery for interactive realtime applications and much lower latency for streaming applications and a combination thereof. draft-jennings-moq-arch specifies architectural aspects of QuicR, a media delivery protocol based on publish/subscribe metaphor and Relay based delivery tree, that enables a wide range of realtime applications with different resiliency and latency needs. This specification defines the protocol aspects of the QuicR media delivery architecture. "BGP SR Policy Extensions for metric", KaZhang, Jie Dong, 2022-11-06, 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 need carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. "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, 2022-07-11, 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. "Careful resumption of congestion control from retained state with QUIC", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom Jones, Christian Huitema, 2022-07-10, This document discusses careful resumption of congestion control parameters in QUIC with a cautious method that enables faster startup of new connections. The method uses a set of computed congestion control parameters that are based on the previously observed path characteristics, such as the bottleneck bandwidth, available capacity, or the RTT. These parameters are stored and can then used to modify the congestion control behaviour of a subsequent connection. The draft discusses assumptions around how a server ought to utilise these parameters to provide opportunities for a new connection to more quickly get up to speed (i.e. utilise available capacity). It discusses how these changes impact the capacity at a shared network bottleneck and the response that is needed after any indication that the new rate is inappropriate. "Semantic Address Based Instructive Routing for Satellite Network", Lin Han, Alvaro Retana, Richard Li, 2022-09-02, This document presents a method to do IP routing over satellite network that consists of LEO (Low Earth Orbit) satellites and ground- stations. The method uses the source routing mechanism. The whole routing info is obtained by path calculation. The routing path information is converted to be a list of instructions and embedded into user packet's IPv6 extension header. At each hop or each satellite, the routing process engine will forward the packet based on the specified instruction for the satellite. Until the packet reaches the edge of satellite network, or the last satellite, the packet will be sent to a ground station. "An IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record", Donald Eastlake, Haoyu Song, 2022-11-27, A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. "5G Distributed UPFs", Zhaohui Zhang, Keyur Patel, Tianji Jiang, Luis Contreras, 2022-07-11, This document describes evolution of mobile user plane in 5G, including distributed UPFs and alternative user plane implementations that some vendors/operators are pushing without changing 3GPP architecture/signaling. This also sets the stage for discussions in a companion document about potentially integrating UPF and Acess Node (AN) in a future generation (xG) of mobile network. "Mobile User Plane Evolution", Zhaohui Zhang, Keyur Patel, Luis Contreras, Kashif Islam, 2022-10-24, [I-D.zzhang-dmm-5g-distributed-upf] 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. Building on top of that, this document further discusses potentially integrating UPF and Access Node (AN) in a future generation (xG) of mobile network. 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. "Use Cases for Computing-aware Software-Defined Wide Area Network(SD-WAN)", Shuai Zhang, Li Jianfei, Cheng Li, Xia Chen, 2022-09-07, SD-WAN is aware of the computing power of applications deployed in the multiple sites of enterprise and can perform the routing policy according to such information. This is defined as the computing- aware SD-WAN.This document describes the use cases for computing- aware Software-Defined Wide Area Network(SD-WAN). "MSR6(Multicast Source Routing over IPv6) Use Cases", Yisong Liu, Feng Yang, Aijun Wang, XueruZhang, Xuesong Geng, Zhenbin Li, 2022-07-11, MSR6 (Multicast Source Routing over IPv6) defines multicast replication as a Layer 3 function. It reuses existing IPv6 headers, functions, and capabilities to forward packets through non-multicast nodes, and adds no flow state at intermediate network nodes. This document introduces the use cases for MSR6. "LSR for SR Proxy Forwarding", Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu, Yisong Liu, 2022-09-04, This document describes extensions to OSPF and IS-IS to support SR proxy forwarding mechanism for fast protecting the failure of a node with segments on a SR-TE path. The segments of the node include adjacency, node or binding segments. "Oblivious Relay Feedback", Tirumaleswar Reddy.K, Dan Wing, Mohamed Boucadair, Roberto Polli, 2022-10-24, Servers often rate-limit incoming requests, for example, rate-limit based upon the source IP address to provide equitable service to clients. However, oblivious HTTP removes the ability for the server to distinguish amongst clients so the server can only rate-limit traffic from the oblivious relay. This harms all clients behind that oblivious relay. This specification enables a server to convey rate-limit information to an oblivious relay, which can use it to apply rate-limit policies on clients. Cooperating oblivious relays can thus provide more equitable service to their distinguishable clients without impacting on all clients behind that oblivious relay. "Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks", Sheng Liu, Haomian Zheng, Aihua Guo, Yang Zhao, Daniel King, 2022-10-20, Many applications, including optical leased line, cloud VR and computing cloud, benefit from the network scenario where the data traffic to cloud data centers (DCs) is carried end-to-end over an optical network. This document describes the problem statement and requirements for connecting to cloud DCs over optical networks, and presents a gap analysis for existing control plane protocols for supporting this network scenario. "Multicast Tree Setup via PCEP", Huanan Li, Aijun Wang, Zhaohui Zhang, Huaimo Chen, Ran Chen, 2022-09-20, Multicast forwarding requires per-tree state on certain nodes. Even with BIER, per-tree state is needed on ingress/egress BIER routers (though not needed on transit BIER routers). This documents specifies PCEP protocol to collect tree information (e.g. root, leaf, constraints) to allow a PCE to calculate a tree, and the procedures to set up per-tree forwarding state on relevant nodes for various multicast trees and various replication technologies. "User-assisted Trust Establishment (EAP-UTE)", Jan-Frederik Rieckers, 2022-09-22, The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-UTE authentication method for a User-assisted Trust Establishment between the peer and the server. The EAP method is intended for bootstrapping Internet-of-Things (IoT) devices without preconfigured authentication credentials. The trust establishment is achieved by transmitting a one-directional out-of-band (OOB) message between the peer and the server to authenticate the in-band exchange. The peer must have a secondary input or output interface, such as a display, camera, microphone, speaker, blinking light, or light sensor, so that dynamically generated messages with tens of bytes in length can be transmitted or received. "Considerations of deploying AI services in a distributed approach", Yong-Geun Hong, Oh Seokbeom, Joo-Sang Youn, SooJeong Lee, Hyun-Kook Kahng, Seung-Woo Hong, Ho-Sun Yoon, 2022-10-24, 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 system in terms of AI inference service to provide AI service in a distributed approach. 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. "ASPA Verification in the Presence of Regionalized AS-Relationships", Chen Shen, Shicong Zhang, Tianran Zhou, Shunwan Zhuang, Shuanglong Chen, Haibo Wang, 2022-08-15, This document proposes a method for ASPA verification in the Presence of Regionalized AS-Relationships. "Registering Self-generated IPv6 Addresses using DHCPv6", Warren Kumari, Suresh Krishnan, Sheng Jiang, Rajiv Asati, Lorenzo Colitti, Jen Linkova, 2022-10-24, This document defines a method to inform a DHCPv6 server that a device has a self-generated or statically configured address. "A YANG Data Model for Network Hardware Inventory", Chaode Yu, Italo Busi, Aihua Guo, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Oscar de Dios, Victor Lopez, 2022-10-24, This document defines a YANG data model for network hardware inventory data information. The YANG data model presented in this document is intended to be used as the basis toward a generic YANG data model for network hardware inventory data information which can be augmented, when required, with technology-specific (e.g., optical) inventory data, to be defined either in a future version of this document or in another document. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "PCEP extensions for Circuit Style Policies", Samuel Sidor, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone, Luay Jalil, Shuping Peng, Tarek Saad, Dan Voyer, 2022-07-06, 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. "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", Acee Lindem, Aditya Dogra, 2022-07-09, This document defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". 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 VRRP Active Router, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup Routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. 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. 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 VRRP Version 3 [RFC5798]. "Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries", Donald Eastlake, Haoyu Song, 2022-08-23, A method of encoding communication service quality requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more label of the name being queried. This enables DNS responses that are dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). "IGP extensions for Advertising Offset for Flex-Algorithm", Louis Chan, Krzysztof Szarkowicz, 2022-09-04, This document describes the IGP extensions to provide predictable Adjacency-SIDs per Flex-Algorithm [FLEXALGO] in segment routing. We propose some methods to allow the advertisement of additional TLV in IGP so that the Flex-Algorithm specific Adjacency-SIDs could be automatically derived. With the proposed method, the size of advertisement on per node per link basis is greatly reduced. Each participating router would derive the required labels automatically. Extensions for offset to derive Flex-Algorithm Prefix-SID is also included in the document. "RAW multidomain extensions", Carlos Bernardos, Alain Mourad, 2022-09-05, This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. "STAR: Distributed Secret Sharing for Private Threshold Aggregation Reporting", Alex Davidson, Shivan Sahib, Peter Snyder, Christopher Wood, 2022-10-24, Servers often need to collect data from clients that can be privacy- sensitive if the server is able to associate the collected data with a particular user. In this document we describe STAR, an efficient and secure threshold aggregation protocol for collecting measurements from clients by an untrusted aggregation server, while maintaining K-anonymity guarantees. "Supporting Bottleneck Structure Graphs in ALTO: Use Cases and Requirements", Jordi Ros-Giralt, Sruthi Yellamraju, Qin WU, Luis Contreras, Y. Yang, Kai Gao, 2022-09-23, This document proposes an extension to the base Application-Layer Traffic Optimization (ALTO) protocol to support bottleneck structures as an efficient representation of the state of a network. Bottleneck structures are efficient computational graphs that allow network operators and application service providers to optimize application performance in a variety of communication problems including routing, flow control, flow scheduling, bandwidth prediction, and network slicing, among others. This document introduces a new abstraction called Bottleneck Structure Graph (BSG) and the necessary requirements to integrate it into the ALTO standard. "YANG Data Model for Network Resource Partition Policy", Vishnu Beeram, Tarek Saad, Bin Wen, Daniele Ceccarelli, Shaofu Peng, Ran Chen, Luis Contreras, Xufeng Liu, 2022-10-24, A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support services (like IETF Network Slices) that need logical network structures with required characteristics to be created. An NRP policy is a policy construct that enables instantiation of mechanisms in support of service specific control and data plane behaviors on select topological elements associated with the NRP. This document defines a YANG data model for the management of NRP policies on NRP capable nodes and controllers in IP/MPLS networks. "Encrypted Client Hello Deployment Considerations", Andrew Campling, Paul Vixie, David Wright, Arnaud Taddei, Simon Edwards, 2022-11-07, 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, 2022-10-10, Ethernet VPN 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, 2022-09-08, 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. "Countersigning COSE Envelopes in Transparency Services", Henk Birkholz, Maik Riechert, Antoine Delignat-Lavaud, Cedric Fournet, 2022-10-24, A transparent and authentic Transparent Registry service in support of a supply chain's integrity, transparency, and trust requires all peers that contribute to the Registry operations to be trustworthy and authentic. In this document, a countersigning variant is specified that enables trust assertions on Merkle-tree based operations for global supply chain registries. A generic procedure for producing payloads to be signed and validated is defined and leverages solutions and principles from the Concise Signing and Encryption (COSE) space. "An Architecture for Trustworthy and Transparent Digital Supply Chains", Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, 2022-10-24, 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 memo defines a generic and scalable architecture to enable transparency across any supply chain with minimum adoption barriers for producers (who can register their claims on any Transparency Service (TS), with the guarantee that all consumers will be able to verify them) and enough flexibility to allow different implementations of Transparency Services with various auditing and compliance requirements. "The IETF Will Continue Maintaining IPv4", Seth Schoen, John Gilmore, David Taht, 2022-08-22, This document confirms the consensus of the IETF that IETF and its affiliated working groups will continue to maintain the IPv4 protocol family. "IPv6-Only PE Design All SAFI", Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2022-09-25, 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 be able to continue to support IPv4 customers when both the Core and Edge networks are IPv6-Only. This document details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv6-Only PE Design, IPv4 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv6-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv6 address need only be configured on the PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. This document defines the IPv6-Only PE Design as a new PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is described in the POC testing document [I-D.ietf-bess-ipv6-only-pe-design] which is now extended to support to all AFI/SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-B, Option-AB and Option-C are still applicable and thus this extension of IPv6-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well. "Problem Statement and Use Cases of Adaptive Traffic Data Collection", Xiaoming He, Dongfeng Mao, Qiufang Ma, Tianran Zhou, 2022-09-19, IP carrier network needs to provide real-time traffic visibility to help network operators quickly and accurately locate network congestion and packet loss, and make timely path adjustment for deterministic services in order to avoid congestion. It is essential to explore the adaptive traffic data collection mechanism so as to capture real-time network state at minimum resource consumption. This document summarizes the problems currently faced by network operators when attempting to provide timely traffic data collection to satisfy various scenarios that require real-time network state and traffic visibility, and aggregates the requirements for adaptive traffic collecting mechanism from a variety of deployment scenarios. "IOAM Linkage Solution for the Protection Cases of 5G Bearer Network", Zhenwen Li, 2022-07-11, In-band operation and maintenance management (IOAM, In-band OAM), as a network performance monitoring technology, is based on the principle of path-associated detection to perform specific field marking/coloring and identification on actual service flows, and perform packet loss and delay measurement. It can quickly perceive network performance-related faults, and accurately delimit boundaries and do troubleshooting. However, the current IOAM solution has shortcomings too. For example, after the service traffic path switching, the IOAM cannot continue working. This paper proposes a scheme to achieve automatic performance monitoring through service path switching and linkage with IOAM, which enhances the feasibility of the IOAM scheme in large-scale deployment and the completeness of IOAM technology. "Related Certificates for Use in Multiple Authentications within a Protocol", Alison Becker, Rebecca Guthrie, Michael Jenkins, 2022-06-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. "The Architecture of Network-Aware Domain Name System (DNS)", Haoyu Song, Donald Eastlake, 2022-09-19, A simple method of enhancing Domain Name System (DNS) with network awareness is discussed. This 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. "Recommendations for Creating IANA-Maintained YANG Modules", Mohamed Boucadair, 2022-10-07, This document provides a set of guidelines for YANG module authors related to the design of IANA-maintained modules. These guidelines are meant to leverage existing IANA registries and use YANG as another format to present the content of these registries when appropriate. This document updates RFC 8407 by providing additional guidelines for IANA-maintained modules. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. This document does not change anything written in RFC 8407 and RFC 8126. "Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2022-10-03, The datagram exchanged between two Internet endpoints have to go through a series of physical and virtual links that may have different limits on the upper size of the datagram they can transmit without fragmentation. Because fragmentation is considered harmful, most transports and protocols are designed with a mechanism that permits dynamic measurement of the maximum size of a datagram. This mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD). But the UDP transport and some of the protocols that use UDP were designed without that feature. The Session Traversal Utilities for NAT (STUN) Usage described in this document permits retrofitting an existing UDP-based protocol with such a feature. Similarly, a new UDP-based protocol could simply reuse the mechanism described in this document. "IGP Unreachable Prefix Announcement", Peter Psenak, Clarence Filsfils, Stephane Litkowski, Dan Voyer, Amit Dhamija, 2022-09-26, 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 existing protocol mechanisms in IS-IS and OSPF to advertise such prefix reachability loss. "BGP SR Policy Extensions for Segment List Identifier", Changwang Lin, Mengxiao Chen, Weiqiang Cheng, Jiang Wenying, 2022-09-28, 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. "Tracing process in IPv6 VPN Tunneling Networks", Yuanyang Yin, Shuping Peng, zhaoranxiao, 2022-06-28, 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 ICMPv4 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, 2022-09-13, This document specifies a diagnostic payload format to be returned in TCP RST segments. Such payloads are used to share with the endpoints the reasons for which a TCP connection has been reset. This is meant to ease diagnostic and troubleshooting. "LISP for Satellite Networks", Dino Farinacci, Victor Moreno, Padma Pillay-Esnault, 2022-09-23, 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, 2022-08-08, 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. "HTTP Access Service Description Objects", Benjamin Schwartz, 2022-10-18, HTTP proxies can operate several different kinds of access services. This specification provides a format for identifying a collection of such services. 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-schwartz-masque-access- descriptions/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/access-services. "Key Consistency by Double-Checking via a Semi-Trusted Proxy", Benjamin Schwartz, 2022-10-19, Several recent IETF privacy protocols require clients to acquire bootstrap information for a service in a way that guarantees both authenticity and consistency, e.g., encrypting to the same key as many other users. This specification defines a procedure for transferring arbitrary HTTP resources in a manner that provides these guarantees. The procedure relies on access to a semi-trusted HTTP proxy, under the same security assumptions as an Oblivious HTTP Relay. "SM2 Digital Signature Algorithm for DNSSEC", Cuiling Zhang, Yukun Liu, Feng Leng, Qi Zhao, Zheng He, 2022-07-26, This document describes how to specify SM2 Digital Signature Algorithm keys and signatures in DNS Security (DNSSEC). It lists the curve and uses SM3 as hash algorithm for signatures. "Advertising Exclusive Links for Flex-Algorithm in IGP", Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Ran Chen, Yanrong Liang, 2022-08-29, This document proposes the method to advertise exclusive links for Flex-Algorithm in IGP. "Active Update of DNS Cache", Zhang Xinqing, Wu Shuangli, Yifang Qin, Wei Wang, Xu Zhou, 2022-07-07, Under the caching mechanism in [RFC1035], the local DNS server cannot obtain the update status of the authoritative server in time, this makes the data inconsistent. Shortening TTL increases server load. In the passive query of the authoritative server, an active notification method is added to update the DNS mapping cache of the local DNS server in order to improve the efficiency of DNS resolution. Authoritative servers actively send DNS update packets after updating resource records. This document designs the API for receiving DNS update packets on the local DNS server. "The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO", Ziyang Xing, Xiaoqiang Di, Hui Qi, 2022-08-20, This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MP_QUIC) 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. "Guidelines for Network Operating System Testing", Yubo Mu, 2022-10-09, This document presents a list of tests for implementers of Network Operating System(NOS) compliant Processes. This document specifies guidelines for a series of tests that can be run to probe the conformity and robustness of the NOS implementations. These tests cover several important functions, in order to gain a level of confidence in the NOS implementation. "DetNet Deterministic Latency Option for IPv6", Quan Xiong, Aihua Liu, 2022-09-29, This document introduces new IPv6 options to identify the Deterministic Latency related information for DetNet flows in IPv6 and SRv6 networks. "SR Policies Extensions for NRP in BGP-LS", Ran Chen, Detao Zhao, Liyan Gong, 2022-10-19, This document defines a new TLV which enable the headed to report the configuration and the states of SR policies carrying NRP information by using BPG-LS. "SRv6 Egress Protection in Multi-homed scenario", Weiqiang Cheng, Jiang Wenying, Changwang Lin, Zhibo Hu, Yuanxiang Qiu, 2022-10-24, This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. "Epoch Markers", Henk Birkholz, Thomas Fossati, Wei Pan, Carsten Bormann, 2022-10-24, 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, 2022-06-29, 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. "DNS message fragments", haisheng yu, Yan Liu, 2022-11-07, This document describes a method to transmit DNS messages over multiple UDP datagrams by fragmenting them at the application layer. The objective is to allow authoriative servers to successfully reply to DNS queries via UDP using multiple smaller datagrams, where larger datagrams may not pass through the network successfully. "Secure Asset Transfer Protocol", Martin Hargreaves, Thomas Hardjono, Rafael Belchior, 2022-11-07, This memo This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit to ensure the properties of transfer atomicity, consistency, isolation and durability. "Routers Verses Hosts; Devices Verses Functions", Mark Smith, 2022-08-23, This memo discusses the differences between routers verses hosts, as devices verses functions. "Network-based mobility management in Dyncast network environment", Jaehwoon Lee, 2022-09-15, Dynamic anycast (Dyncast) 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 Dyncast anycast Node (DAN) by using the PMIPv6-based mobility management method in the Dyncast-based edge computing networking environment. "Dangerous Labels in DNS and E-mail", Daniel Gillmor, 2022-10-13, This document establishes registries that list known security- sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. "Multicast Extension for QUIC", Jake Holland, Lucas Pardue, Max Franke, 2022-07-11, 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. "Automated Certificate Management Environment (ACME) Device Attestation Extension", Brandon Weeks, 2022-08-07, 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. "An Advanced Scheduling Option for Multipath QUIC", Yunfei Ma, Yanmei Liu, Christian Huitema, Xiaobo Yu, 2022-11-17, This document specifies an advanced scheduling option for multipath QUIC protocol. The goal is to enable the use of multipath QUIC for applications that have tight latency constraints. For general purpose multipath packet scheduling, please refer to [I-D.bonaventure-iccrg-schedulers]. 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/yfmascgy/draft-ma-quic-advance-scheduling. "SCION Overview", Corine de Kater, Nicola Rustignoli, Adrian Perrig, 2022-08-26, 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. A more detailed analysis of relationships and dependencies between components is available in [I-D.rustignoli-scion-components]. As SCION is already in production use today, the document concludes with an overview of SCION deployments. "Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE)", Gyan Mishra, Jeff Tantsura, 2022-11-10, The 4Provider Edge (4PE) design explains how to interconnect IPv4 islands over a Multiprotocol Label Switching (MPLS) LDPv6 enabled IPv6-Only core, Segment Routing (SR) enabled SR-MPLS IPv6-Only core or SRv6 IPv6-Only core. The 4PE routers exchange the IPv4 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv6. In doing so, the BGP Next Hop field is used to convey the IPv6 address of the 4PE router so that dynamically established IPv6-signaled MPLS Label Switched Paths (LSPs) or SRv6 Network Programming IPv6 forwarding path instantiation and can be utilized without any explicit tunnel configuration. "IPv4-Only PE Design for IPv6-NLRI with IPv4-NH", Gyan Mishra, Jeff Tantsura, Mankamana Mishra, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2022-07-07, As Enterprises and Service Providers try to decide whether or not to 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) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv4-Only. This document details an important External BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-BGP capability exchange by using IPv4 peering as pure transport, allowing both IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session. The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this design change from a control plane perspective a single IPv4 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding. This document provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides vendor specific test cases for the IPv4-Only peering 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 IPv4-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 this new Best Current Practice for eBGP IPv4-Only Edge peering. This Best Current Practice IPv4-only eBGP peering design specification will help in use cases where operators are not yet ready to migrate to IPv6 or SRv6 core or for very lage operator core with thousdands of nodes where it maybe impractical to change the underlay infrastructure to IPv6, and can now keep the existing IPv4 data plane IP, MPLS or SR-MPLS underlay intact indefinitely. This document also defines a new IPv4 next hop encoding for IPv6 NLRI over IPv4 Next Hop to uses 4 byte IPv4 address for the next hop and not a IPv4 mapped IPv6 address. This encoding has been adopted by the industry but has not been standardized until now with this document. "EVPN Mpls Ping Extension", DIKSHIT Saumya, Gyan Mishra, Srinath Rao, Santosh Easale, Ashwini Dahiya, 2022-11-20, 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. "FC1: A Non-Deterministic, Alien-Resistant, Cipher Where The Modulo Is The Symmetric Key", Michele Fabbrini, 2022-11-21, In this paper we describe a symmetric key algorithm that offers an unprecedented grade of confidentiality. Based on the uniqueness of the modular multiplicative inverse of a positive integer a modulo n and on its computability in a polynomial time, this non-deterministic cipher can easily and quickly handle keys of millions or billions of bits that an attacker does not even know the length of. The algorithm's primary key is the modulo, while the ciphertext is given by the concatenation of the modular inverse of blocks of plaintext whose length is randomly chosen within a predetermined range. In addition to the full specification here defined, in a related work we present an implementation of it in Julia Programming Language, accompanied by real examples of encryption and decryption. "FC1 Algorithm Ushers In The Era Of Post-Alien Cryptography", Michele Fabbrini, 2022-11-21, This memo aims to introduce the concept of "post-alien cryptography", presenting a symmetric encryption algorithm which, in our opinion, can be considered the first ever designed to face the challenges posed by contact with an alien civilization. FC1 cipher offers an unprecedented grade of confidentiality. Based on the uniqueness of the modular multiplicative inverse of a positive integer a modulo n and on its computability in a polynomial time, this non-deterministic cipher can easily and quickly handle keys of millions or billions of bits that an attacker does not even know the length of. The algorithm's primary key is the modulo, while the ciphertext is given by the concatenation of the modular inverse of blocks of plaintext whose length is randomly chosen within a predetermined range. In addition to the full specification here defined, in a related work we present an implementation of it in Julia Programming Language, accompanied by real examples of encryption and decryption. "Service Aware Network Framework", Daniel Huang, Bin Tan, Dong Yang, 2022-11-22, Cloud has been migrating from concentrated center sites to edge nodes with responsive and agile services to the subscribers. This industry-wide trend would be reasonably expected to continue into the future which would enjoy geographically ubiquitous services. Rather than transmitting service data streams to the stable and limited service locations such as centered cloud sites, routing and forwarding network will have to adapt to the emerging scenarios where the service instances would be highly dynamic and distributed, and further more, demand more fine-grained networking policies than the current routing and forwarding scheme unaware of service SLA requirements. This proposal is to demonstrate a framework under which the above-mentioned requirements would be satisfied. "Transport Layer Security (TLS) Extension: Validation Request", Robert Segers, Ashley Kopman, 2022-08-24, This document describes the Server-based Certificate Validation Protocol (SCVP) Validation Request extension to the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The Validation Request Extension provides a new protocol for TLS/DTLS allowing inclusion of SCVP certificate path validation information in the TLS/DTLS handshake. "Path Tracing in SR-MPLS networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Israel Meilik, Mike Valentine, Ruediger Geib, Jonathan Desmarais, 2022-11-21, 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], [I-D.ietf-ippm-ioam-data], [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]. "Entity Attestation Token (EAT) Collection Type", Simon Frost, 2022-06-27, The default top-level definitions for an EAT [I-D.ietf-rats-eat] assume a hierarchy involving a leading signer within the Attester. Some token use cases do not match that model. This specification defines an extension to EAT allowing the top-level of the token to consist of a collection of otherwise defined tokens. "Secure Asset Transfer (SAT) Interoperability Architecture", Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna, 2022-12-02, This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. "The Architecture for Internet of Things Network", Yan Liu, Yang Song, haisheng yu, 2022-11-07, In this document, it identifies gateways for field-bus networks, data storages for archiving and developing data sharing platform, and application units to be important system components for developing digital communities: i.e., building-scale and city-wide ubiquitous facility networking infrastructure. The standard defines a data exchange protocol that generalizes and interconnects these components (gateways, storages, application units) over the IPv6-based networks. This enables integration of multiple facilities, data storages, application services such as central management, energy saving, environmental monitoring and alarm notification systems. "BGP Extensions of SR Policy for Headend Behavior", Changwang Lin, Jiang Wenying, Yisong Liu, Mengxiao Chen, Hao Li, 2022-06-10, This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. "Distribute SRv6 Locator by DHCP", Weiqiang Cheng, RuiboHan, Changwang Lin, Yuanxiang Qiu, 2022-11-06, In SRv6 network, locators need to be assigned to each SRv6 Endpoint, and segments are created based on locators. This document describes the method of assigning locators to SRv6 Endpoints through DHCPv6. "Parametrized Content-Format for CoAP", Thomas Fossati, Henk Birkholz, 2022-10-17, This document specifies a "parametrized" CoAP Content-Format data item that allows supplementing a Content-Format with additional media type parameters. This document also defines two new CoAP Options, Parmetrized-Content- Format and Parametrized-Multi-Valued-Accept, that build upon the "parametrized" Content-Format data item to work around some of the limitations of the existing Accept and Content-Format Options. "LSP Ping/Traceroute for SR-MPLS NRP SIDs", Liu Yao, Shaofu Peng, 2022-06-13, [RFC8287] defines the extensions to MPLS LSP ping and traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs with an MPLS data plane. To correctly identify and validate an SR NRP SID, the validating device also requires NRP-ID to be supplied in the FEC Stack sub-TLV. This document introduces new Target FEC Stack sub- TLVs to perform MPLS LSP ping and traceroute for NRP SIDs. "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)", Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery, 2022-09-10, Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding dropping 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. "Client Roaming Control", Eugene Adell, 2022-06-15, This document describes the Client Roaming Control (CRC) technique to allow an organization to control the access to third-party applications over Internet. It specifies the _crc Global Underscored Node Name for organizations willing to implement this technique. A new Client Roaming Support (CRS) Resource Record is also introduced for the applications supporting an authorization mechanism honoring the CRC, in order to inform of this support. "Extensible In-band Processing (EIP) Architecture and Framework", Stefano Salsano, Hesham ElBakoury, Diego Lopez, 2022-06-15, 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. "a simple way to provide informations for contributors", Valentin Binotto, 2022-10-01, Open source projects rely on the cooperation of third parties. Other websites also rely on user feedback, for example, when bugs occur. There are various platforms that enable effective collaboration. However, this diversity also presents a challenge. Where should users who have discovered an error report it? Or how can third parties participate in a project? This document presents one way to communicate such information in a consistent manner. "IPv6 Options for Cyclic Queuing and Forwarding Variants", Yizhou Li, Shoushou Ren, Guangpeng Li, Fan Yang, Jeong-dong Ryoo, Peng Liu, 2022-10-24, The fundamental Cyclic Queuing and Forwarding (CQF) defined by Time- Sensitive Networking (TSN) requires no per-stream per-hop state maintenance and at the same time its end-to-end bounded latency and jitter can be easily computed. Such features are attractive and therefore CQF is being considered in wider deployments. To accommodate the different deployments, there are variants of CQF enhancement. This document introduces a new IPv6 option to include the cycle identification to help leverage CQF variants in DetNet network to facilitate the deployments. "S-BFD Proxy", Qing Yang, Feng Zhu, Victor Wen, Jianwei Hu, Beixin Huang, Nian Liu, 2022-06-23, This document proposes an extension to Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD initiator will send packets that carry extra information, and this enables reflector to act as a proxy, and respond with the extra information in consideration. This document updates RFC 7880. "A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF", Mahesh Jethanandani, Keyur Patel, 2022-10-12, This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. "IPv4-Only PE Design All SAFI", Gyan Mishra, Jeff Tantsura, Mankamana Mishra, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2022-10-24, As Enterprises and Service Providers try to decide whether or not to 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) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv4-Only. This specification details an important External BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-BGP capability exchange by using IPv4 peering as pure transport, allowing both IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session. The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this design change from a control plane perspective a single IPv4 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding. This specification provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides vendor specific test cases for the IPv4-Only peering 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 IPv4-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 this new Best Current Practice for eBGP IPv4-Only Edge peering. This Best Current Practice IPv4-only eBGP peering design specification will help in use cases where operators are not yet ready to migrate to IPv6 or SRv6 core or for very lage operator core with thousdands of nodes where it maybe impractical to change the underlay infrastructure to IPv6, and can now keep the existing IPv4 data plane IP, MPLS or SR-MPLS underlay intact indefinitely. This document also defines a new IPv4 next hop encoding for IPv6 NLRI over IPv4 Next Hop to uses 4 byte IPv4 address for the next hop and not a IPv4 mapped IPv6 address. This encoding has been adopted by the industry but has not been standardized until now with this document. This document details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv4-Only PE Design, IPv6 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv4-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. This document defines the IPv4-Only PE Design as a new PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard defined in this specification which is now extended to support to all AFI/ SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-B, Option-AB and Option-C are still applicable and thus this extension of IPv4-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well. "Framework of Multi-domain IPv6-only Network", Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Mohamed Boucadair, 2022-06-20, For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 transfer capabilities are deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 transfer capabilities are used while ensuring global reachability for both IPv6 and IPv4(IPv4aaS). This document specifies requirements and propose a general framework when deploying IPv6-only in multi-domain network. "Privacy Considerations for Web Feed Readers", Mark Nottingham, 2022-06-21, This specification collects privacy-enhancing guidelines for Web feed readers. 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-nottingham-feed-privacy/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/feed-privacy. Note to Readers This draft is a quick straw-man; it is intended to assess implementer and community interest in the topic, not to state concrete requirements (yet). Feedback much appreciated. "Concise TA Stores (CoTS)", Carl Wallace, Russ Housley, Thomas Fossati, Yogesh Deshpande, 2022-10-10, 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. "SDP Offer/Answer for RTP using QUIC as Transport - Design Issues", Spencer Dawkins, 2022-06-22, This document is intended to capture SDP aspects of RTP over QUIC design issues that have arisen, been discussed by the AVTCORE working group, and have reached a resolution that can be included in "SDP Offer/Answer for RTP using QUIC as Transport". This document is a companion document to "SDP Offer/Answer for RTP using QUIC as Transport". That document focuses on the description and registration of SDP "proto" attribute parameters with IANA, to allow applications that rely on SDP Offer/Answer to negotiate the QUIC protocol as an encapsulation for RTP. "SDP Offer/Answer for RTP using QUIC as Transport" is itself a companion document to "RTP over QUIC", and follows the lead of the latter specification as it evolves. "RTP Control Protocol (RTCP) Messages for Green Metadata", Yong He, Waqar Zia, Christian Herglotz, Edouard Francois, 2022-07-29, This memo 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 document 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. "REST API Linked Data Keywords", Roberto Polli, 2022-06-23, This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents. 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-polli-restapi-ld-keywords/. information can be found at https://github.com/ioggstream/draft- polli-restapi-ld-keywords. Source for this draft and an issue tracker can be found at https://github.com/ioggstream/draft-polli-restapi-ld-keywords/issues. "MPLS Sub-Stack Encapsulation for Deterministic Latency Action", Xueyan Song, Quan Xiong, 2022-11-06, This document specifies formats and principals for the MPLS header which contains the Deterministic Latency Action (DLA) information, designed for use over a DetNet network with MPLS data plane. It enables guaranteed delay support and makes scheduling decisions for time-sensitive service running on DetNet nodes that operate within a constrained network domain. "Framework of Multi-domain IPv6-only Underlay Networks and IPv4 as a Service", Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Mohamed Boucadair, Thomas Graf, 2022-10-21, 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 transfer capabilities are used while ensuring global reachability for both IPv6 and IPv4 (usually known as IPv4aaS). This document specifies requirements and proposes a framework for deploying IPv6-only as the underlay in multi-domain networks, discusses the requirements of service traffic, major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery. The document also discusses related considerations with security. "Asynchronous Deterministic Networking Framework for Large-Scale Networks", Jinoo Joung, Jeong-dong Ryoo, Tae-sik Cheung, Yizhou Li, Peng Liu, 2022-10-24, This document describes an overall framework of Asynchronous Deterministic Networking (ADN) for large-scale networks. It specifies the functional architecture and requirements for providing latency and jitter bounds to high priority traffic, without strict time-synchronization of network nodes. "Inter-Gateway Discovery and Communications in Building Automation Systems", Michael Richardson, Wei Pan, 2022-06-26, This document describes a use case where gateways need to discover each other in order to maintain building safety systems "Use Case of Remote Driving and its Network Requirements", Lijun Dong, Richard Li, Jungha Hong, 2022-06-27, This document illustrates the use case of remote driving that leverages the human driver's advanced perceptual and cognitive skills to enhance autonomous driving when it is absent or falls short. Specifically the document analyzes the end-to-end latency that is required in the network to support collision avoidance in remote driving. The document also summarizes the other necessary requirements that the networking services shall support. "IoT Information-Model Standards Description ("Nutrition Label")", Milenkovic, 2022-06-27, Implementation of IoT systems imposes a requirement of M2M semantic interoperability. This problem is addressed by a number of ongoing attempts to define and standardize IoT information and data models. At present this work is fragmented across several standards with different approaches, scope, objectives, terminology, and assumptions that makes them difficult to understand and compare. This document is part of the effort to alleviate that problem by means of more streamlined presentations and descriptions. We are advocating for clear articulation of the intent and implicit or explicit assumptions in SDO specifications using the common terminology. Such clarifications would aid IoT practitioners and potential adopters to make meaningful comparisons and facilitate selection of IoT specifications that are the best fit for their intended purpose. To that end, we propose that creators of IoT standards address a list of questions that would characterize their work in comparable ways, somewhat akin to the intent of nutrition labels for food. This paper describes the basic design principles and practices of IoT information and data model definitions, and proposes an initial list of questions that SDOs may address to facilitate understanding and comparisons. Our intent is to evolve and refine this list over time by actively soliciting and incorporating feedback and suggestions of IoT community. "Credentials Provisioning and Management via EAP (EAP-CREDS)", Massimiliano Pala, Yuan Tian, 2022-06-30, 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. "Credentials Provisioning and Management via EAP Method (EAP-CREDS)", Massimiliano Pala, Yuan Tian, 2022-06-30, 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. EAP-CREDS is an EAP method that specifically designed for credential provisioning and management. If implemented in Access Networks (e.g., wired), EAP-CREDS can offer credentials management services such as registration, provisioning, and renewal. Besides, EAP-CREDS provides protocol encapsulation mechanism that allows it to use with other credential management protocols. Therefore, this document defines how to use EAP-CREDS with the Simple Provisioning Protocol (SPP) to support the provisioning and management of authentication credentials for user and/or devices in an access network. Other credential provisioning protocols can also use this document as a guideline and template for its own encapsulation with EAP-CREDS. "Discarding Priority of RTP Video Packets", Lijun Dong, Richard Li, Stuart Clayman, Muge Sayit, 2022-07-10, This document illustrates that significance difference or discarding priority might exist among RTP packets which encapsulate video streaming data with the existing modern video codecs, i.e., H.264/ AVC, SVC, H.265/HEVC and H.266/VVC. The document overviews the RTP NALU header format for the existing modern video codecs. Each contains at least one field that indicates the RTP packet's relative significance within the video stream. With the dominance of video traffic in the Internet, selectively dropping RTP packets from competing video streams according to their significances or discarding priorities could be a complementary mechanism when dealing with network congestion. The document proposes the Differentiated Services Code Point (DSCP) value mapping to the RTP packet discarding priority carried in the RTP NALU header. The document also proposes a new Hop-by-Hop Extension Header (HbH-EH) with a value that is copied from the discarding priority of the RTP packet, if the 6-bit DSCP value is not long enough for the mapping. "Neighbor Discovery support for Multi-home Multi-prefix", Eduard, Paolo Volpato, 2022-09-29, Multi-home Multi-prefix (MHMP) IPv6 environment is the norm for businesses that need to have uplink resiliency. Several solutions have been already discussed and proposed to address MHMP and how it can be enabled in different network contexts. This draft looks at MHMP from the perspective of Neighbour Discovery Protocols (NDP). For any considered destination, the MHMP challenge may be split into 3 sub-challenges (important to solve in the below order): 1) the host should choose the proper source address for the packet, 2) the host should choose the best default router as the next-hop, 3) site topology may be complicated and may need the source routing through the site. This draft is concerned with the solution for the first two problems that need improvement for the ND (RFC 4861) SLAAC (RFC 4862) and Default Address Selection (RFC 6724). The last problem is considered as properly discussed by Multihoming in Enterprise (RFC 8678). "A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies", Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, John Drake, Mohamed Boucadair, Luis Contreras, Ivan Bykov, Reza Rokui, Luay Jalil, Beny Setyawan, 2022-10-24, 5G slicing is a new feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. It covers slicing requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a basic IETF Network Slice realization model in IP/MPLS networks with a focus on fulfilling 5G slicing connectivity requirements. This IETF Network Slice realization model reuses many building blocks currently commonly used in service provider networks. "Secure IP Binding Synchronization via BGP EVPN", DIKSHIT Saumya, Gadekal, Reddy, 2022-07-02, The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. "Problem Statement and Requirements for the Operation and Control Networks (OCNs)", Tooba Faisal, Diego Lopez, Jose Ordonez-Lucena, Kiran Makhijani, 2022-07-02, The emergence of applications based on machine-to-machine communications require control systems to be extended beyond their closed environments. Specifically, autonomous systems that bring about physical and mechanical changes to an environment, heavily rely on their remote operations and control. This document provides an overview of the issues associated with the communications in the control systems to support network-based operations in a generic manner at any-scale environments. The term Operations and Control networks (OCN) is used to describe the common characteristics emerging from the requirements for such control systems. The OCNs are technology-agnostic concept. This document aims to discuss the requirements for establishing common interfaces and functions. "Operations and Control Networks - Reference Model and Taxonomy", Kiran Makhijani, Tooba Faisal, Richard Li, 2022-07-02, This text formulates a specialized network concept to support communication constraints in automated systems. These specialized networks, formulated as Operations and Control networks (OCN), are significant to many application scenarios involving the control and monitoring of mechanical and digital devices. The document defines the OCN reference model, describing the associated components, interfaces, and reference points. The reference model is independent of any specific technology. Standardized mechanisms will facilitate large-scale machine-to-machine communication and help with the integration between OCN and the Internet. "One-way delay measurement method based on Digital Twin Network", Hongwei Yang, Danyang Chen, 2022-10-21, This document implements an accurate network delay measurement method based on the digital twin network. This is a use case of digital twin network. This method does not need to send measurement packets, does not need to change the physical network configuration, does not need to change the format of service packets, do not require physical network elements to support the time synchronization protocol, and support the one-way delay measurement of any service packet.The digital twin network architecture of this document follows the NMRG working group paper draft-irtf-nmrg-network-digital-twin-arch-00. "Digital Twin Network Flow Simulation", Hongwei Yang, Cheng Zhou, 2022-10-21, Some important application scenarios of digital twin network, such as network new technology experiment, network configuration verification, network performance optimization, etc., all require the virtual traffic in the twin network to accurately simulate the real traffic in the physical network.The real traffic in the physical network is called the physical traffic, and the virtual traffic in the twin network is called the twin traffic. In order to realize the high-fidelity simulation of the physical traffic by the twin traffic, this paper proposes that the twin traffic and the physical traffic should satisfy three consistent characteristics, and an implementation method of twin flow is introduced. "Sub-slicing for SRv6", Louis Chan, 2022-07-03, This document describes how to achieve further slicing or traffic engineering interoperability between vendors without the use of SRH. Slicing or traffic engineering information is encapsulated as part of the SRv6 SID. Use of IP longest prefix match approach to identify the further slicing via sub- slice identifier. The traffic engineering from one end to another end is seen as segment by segment approach. This approach could solve the scalability of traffic engineering tunnels required in a huge network, which order of N^2 has be considered. "Forward Requests Return Multicast (FRRM) Communication Semantic", Dirk Trossen, 2022-07-04, This document introduces a communication semantic for multicast that is initiated through forward requests, resulting in dynamic return multicast to the set of initiating clients. The key dynamic nature here is the return multicast relations being possibly different for every transmission. We introduce this semantic more formally, present exemplifying use cases and then focus on realizing this semantic using two multicast technologies. Although this document formally introduces the FRRM semantic as a new communication semantic, it does not intend to show the realization of it through the specific multicast technologies in all details. This is left for separate documents, if desired. "Static Multicast Routing", tathagata nandy, Anil Raj, Muthukumar, Subramanian, 2022-07-05, 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). Unlike the other Multicast Routing protocols, this feature does not depend on Unicast Routing Protocols to build the Multicast tree. 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). "IS-IS extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua Wei, BenChong Xu, 2022-07-24, This document describes the IS-IS protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation. "OSPFv2 extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua Wei, BenChong Xu, 2022-07-05, This document describes the OSPF protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation. "OSPFv3 extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua Wei, BenChong Xu, 2022-07-24, This document describes the OSPFv3 protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation. "Path MTU (PMTU) for Segment Routing Policy", Shuping Peng, Dhruv Dhody, Ketan Talaulikar, Gyan Mishra, 2022-10-23, This document defines the Path MTU (PMTU) for SR Policy (called SR- PMTU) and it applies to both SRv6 and SR-MPLS. The framework of SR- PMTU for SR Policy is specified, including link MTU collection, SR- PMTU Computation, SR-PMTU Enforcement, and Handling behaviors on the headend. "MPLS Network Action (MNA) Header Encodings", Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella, 2022-11-05, This document defines the MPLS Network Action (MNA) Header encoding formats to carry Network Actions and optionally Ancillary Data in the label stack and post label stack. The MPLS Network Action can be used for example, to influence the forwarding decisions or to carry additional OAM information in the MPLS packet. 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. "Early Data Option for CoAP", Hannes Tschofenig, Thomas Fossati, 2022-07-06, This document defines mechanisms that allow clients to communicate with servers about CoAP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. "Destination/Source Routing", David Lamparter, Anton Smirnov, Jen Linkova, Shu Yang, 2022-07-06, 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. "Passive Probing for Path MTU Discovery with QUIC", Pyung Kim, 2022-07-06, This draft consider an alternative PMTUD for QUIC. To discover the best PMTU, the passive probing approach is adopted. The process of discovering the best PMTU is not carried out separately, but is carried out simultaneously in the actual application data communication. 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. Other rather complex discovery algorithms that consider various PMTU candidate sequences will be dealt with in the future. "Proxying Listener UDP in HTTP", David Schinazi, Abhijit Singh, 2022-10-12, 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. "IGP Flexible Algorithm with Common Address", Zhibo Hu, Guoqi Xu, Jie Dong, 2022-07-07, An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. IGP Flex-Algorithm can be used with Segment Routing (SR) or IP data plane. When used with SR data plane, Flex- Algorithm requires to allocate algorithm specific Prefix Segment Identifiers (SIDs) or algorithm specific SRv6 Locators. When used with IP data plane, Flex-Algorithm requires to allocate algorithm specfic IPv4 or IPv6 prefixes. This increases the complexity and overhead of managing, advertising and maintaining additional SR SIDs, SRv6 Locators and IPv4 or IPv6 prefixes, which may not be affordable to some networks and network devices. This document extends IGP Flex-Algorithm to allow the use of common SR SIDs, SRv6 Locators and IP prefixes among multiple Flex- Algorithms. "IGP Flexible Algorithms Reverse Affinity Constraint", Peter Psenak, Jakub Horn, Amit Dhamija, 2022-07-07, An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", Michael Tuexen, Randall Stewart, Peter Lei, Eric Rescorla, 2022-07-08, 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. "Stub Router Flag in ICMPv6 Router Advertisement Messages", Jonathan Hui, 2022-07-07, This document defines a new Stub Router flag in the Router Advertisement message to distinguish configuration information sent by stub routers from infrastructure routers. For example, the Stub Router flag allows stub routers to easily identify when an infrastructure router is advertising a usable IPv6 prefix, triggering the stub router to not advertise its own routable prefix. "OCN Use Cases for Industry control Networks", Cedric Westphal, Kiran Makhijani, Kapal Dev, Luca Foschini, 2022-07-07, This document present industrial networking use cases for Operations and Control Networks (OCN). It is a companion document to the OCN reference model and the OCN problem statement and requirements document. This document compiles a list of potential use cases where new industrial networking protocols could be beneficial. "Terminology for Post-Quantum Traditional Hybrid Schemes", Florence D, 2022-10-20, 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 ensure consistency and clarity across different protocols, standards, and organisations. "Overlay Routing Problem Statement", Shangling Deng, Geng Li, Yong Cui, 2022-07-08, This document considers the limitations of existing technologies in addressing the challenges of low network latency. It analyzes the problem of signaling redundancy on control plane and problem of non- global optimal path selection policy for overlay network and explores possible solutions. "Dynamic-Anycast (Dyncast) Gap analysis and Requirements", Peng Liu, Tianji Jiang, Philip Eardley, Dirk Trossen, Cheng Li, 2022-07-08, This document provides gap analysis and requirements for the problems and use cases that champion the joint optimization of both network and computing resources as outlined in[I-D.liu-dyncast-ps-usecases]. It also identifies the key engineering investigation areas which require adequate architectures and protocols to achieve balanced computing and networking resource utilization among facilities providing the services. "Usecases of SRv6 Based Computing Interconnection Network", Xiaoqiu Zhang, Feng Yang, Weiqiang Cheng, Zhihua Fu, 2022-07-08, 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. "SRv6 Underlay tunnel Programming", Liuyan Han, Minxue Wang, Ran Chen, Aihua Liu, 2022-11-21, This document defines a new SRv6 Endpoint behavior which can be used for SRv6 underlay tunnel (e.g.L1 channel) Programming, called END.BXC, this behavior are used to bind an underlay tunnel. "Cryptographically Generated Addresses (CGA) Light", Eduard, 2022-09-22, This document specifies a method for securely associating link-layer addresses (MAC) to the IPv6 address by a cryptography method similar to blockchain mining. It permits guarantee security at the IPv6 layer to the same degree as at the link layer (that node is dependent on anyway). "METADATA frame for HTTP/2 and HTTP/3", Bence Beky, Biren Roy, 2022-08-01, This document describes a mechanism to send meta information over HTTP/2 and HTTP/3 connections that refers to either the entire connection or a specific stream without changing the semantics of the HTTP messages. This mechanism can be used, for example, to gather information for accounting or logging purposes. "IGP Monitoring Protocol (IMP)", Robert Raszuk, 2022-07-08, This document defines a new point to point protocol to carry information present in link state database of OSPF and ISIS Interior Gateway Protocols (IGPs) as well as in Traffic Engineering Database (TED). "Hierarchical segment routing solution of CAN", Daniel Huang, Zongpeng Du, Chen Zhang, 2022-07-08, CAN (Computing Aware Network) is designed to enable the routing network to be aware of computing status thus deliver the service flow accordingly. Nevertheless, computing and networking is quite different in terms of resource granularity as well as its status stability. It would gain significant benefits to accommodate the computing status to that of networking by employing a hierarchical computing routing segment scheme. The network-accommodated computing status could be maintained at remote CAN nodes while the rest could reside at local CAN nodes. By enabling the network to schedule and route computing services in a compatible way with the current IP routing network, CAN would bring benefits to the industry by both efficiently pooling the computing resources and rendering services through perspective of converged networking and computing. "Consistency for CDS/CDNSKEY and CSYNC is Mandatory", Peter Thomassen, 2022-10-24, Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. [RFC7344] automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. Similarly, CSYNC records indicate a desired update of the delegation's NS records [RFC7477]. Parent-side entities (e.g. Registries, Registrars) typically discover these records by periodically querying them from the child ("polling"), before using them to update the delegation's parameters. This document specifies that if polling is used, 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. "Use Cases for Parent SR Policy", Jiang Wenying, Weiqiang Cheng, Changwang Lin, Yuanxiang Qiu, 2022-07-09, 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", Changwang Lin, Yuanxiang Qiu, 2022-07-09, 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 information can be accurately calculated to realize the source address verification. "NRP ID in SRv6 segment", Yisong Liu, Changwang Lin, Hao Li, Liyan Gong, 2022-10-15, 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, 2022-07-10, 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, 2022-07-10, 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. "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements", Dan Li, Jianping Wu, Lancheng Qin, Mingqing Huang, Nan Geng, 2022-11-29, Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) aims to make improvements to existing intra-domain Source Address Validation (SAV). This document provides the gap analysis of existing intra-domain SAV mechanisms, describes the fundamental problems, and defines the requirements for improvements. "Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement, and Requirements", Jianping Wu, Dan Li, Lancheng Qin, Mingqing Huang, Nan Geng, 2022-11-29, Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) focuses on narrowing the technical gaps of existing source address validation (SAV) mechanisms in inter-domain scenarios. This document provides a gap analysis of existing inter-domain SAV mechanisms, describes the problem statement based on the analysis results, and concludes the requirements for improving inter-domain SAV. "BGP Flowspec for IETF Network Slice Traffic Steering", Jie Dong, Ran Chen, Subin Wang, Jiang Wenying, 2022-10-19, 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 needs to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows which belong to a network slice 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). "RAW multidomain extensions", Carlos Bernardos, Alain Mourad, 2022-07-10, This document addresses the multi-domain DetNet problem, analyzing what the technical gaps are and exploring some possible solutions. Application, control and data plane aspects are in scope. The goal is to help understanding what might be the next steps towards enabling DetNet in multi technology and/or administrative domains. "Data Collection Requirements and Technologies for Digital Twin Network", Cheng Zhou, Danyang Chen, Pedro Martinez-Julia, Qiufang Ma, 2022-11-07, A Digital Twin Network is a virtual representation of a physical network, which is meant to be used by a management system to analyze, diagnose, emulate and control the physical network based on monitoring information, data, models, and interfaces. The construction and state update of a Digital Twin Network require obtaining real-time information of the physical network it represents (i.e., telemetry data). This document aims to describe the data collection requirements and provide data collection methods or tools to build the data repository for building and updating a digital twin network. "Transporting IP/UDP Payload-only in VPNs", Zhaohui Zhang, Keyur Patel, 2022-07-10, This document specifies an option for IP-VPN to transport IP/UDP payload only, without transporting IP/UDP headers, which are removed by an ingress PE and re-added by an egress PE. "Generalized IPv6 Tunnel (GIP6)", Zhenbin Li, Shuanglong Chen, Qiangzhou Gao, Shuai Zhang, Qingbang Xu, 2022-11-06, This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. "Generalized Arguments of SRv6 Segment", Zhenbin Li, Jianwei Mao, Cheng Li, 2022-07-10, 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", Fan Yang, Tianran Zhou, Li Zhang, Zongpeng Du, 2022-10-24, 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. "Research Challenges in Coupling Artificial Intelligence and Network Management", Jerome Francois, Alexander Clemm, Dimitri Papadimitriou, Stenio Fernandes, Stefan Schneider, 2022-10-24, This document is intended to introduce the challenges to overcome when network management problems may require to be couple with AI solutions. On one hand, there are many difficult problems in Network Management 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 SHOULD be 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. "Segment Routing for Enhanced DetNet", Xuesong Geng, Zhenbin Li, Tianran Zhou, 2022-07-11, One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing(SR) and Segment Routing over IPv6 (SRv6) to implement bounded latency. Specifically, new SRv6 SID function is used to specify bounded latency information for a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved by different implementations based on bounded latency information. "IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID", Changwang Lin, Mengxiao Chen, Hao Li, 2022-07-11, The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. "A YANG Data Model for Alternate Marking Method", Minxue Wang, Liuyan Han, Xiao Min, Guo Jun, 2022-07-11, Alternate-Marking Method (AMM) is a technique used to perform packet loss, delay, and jitter measurements on live traffic. This document defines a YANG data model for Alternate Marking Method. "Define the Value 255 in Last Entry field of Segment Routing Header", Tianran Zhou, Jingrong Xie, 2022-07-11, This document proposes to define the value 255 in Last Entry field in Segment Routing Header (SRH) [RFC8754], to indicate an SRH without any SID left. "Network Resource Programming with SRv6", Weiqiang Cheng, Jiang Wenying, Ran Chen, Detao Zhao, Changwang Lin, 2022-07-11, This document defines a new SRv6 network function which can be used for SRv6 Network Resource Programming. A new SRv6 Endpoint behavior is used to associate with a set of network resource partition, called End.NRP. By using the End.NRP SID , the SRv6 policy can provide the capability of network resources programming. "Computing Resource Modeling for CAN", Peng Liu, Zongpeng Du, Lanlan Rui, Wenjing Li, Cheng Li, Daniel Huang, 2022-07-11, This document describes the considerations and potential architecture of modeling the computing resource in the Computing-Aware Network(CAN). Moreover, the network and application based modeling are also presented in this document to meet the potential requirements of integrated and hierarchical modeling. "Internet Addressing Considerations", Luigi Iannone, Dirk Trossen, Paulo Mendes, Nirmala Shenoy, Laurent Toutain, Abraham Chen, Dino Farinacci, Jens Finkhaeuser, Yihao Jia, 2022-09-05, There exist many extensions to Internet addressing, as it is defined in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively. Those extensions have been developed to evolve the addressing capabilities beyond the basic properties of Internet addressing. This document outlines those properties as a baseline against which the extensions are categorized in terms of methodology used to extend the addressing model, together with examples of solutions doing so. While introducing such extensions, we outline the shortcomings we see with those extensions. This ultimately leads to consider whether or not a more consistent approach to tackling the identified use cases, beyond point-wise extensions as done so far, would be beneficial. The benefits are the ones detailed in the companion document [I-D.iannone-scenarios-problems-addressing], where, leveraging on the shortcomings identified in this memo and scenarios provided in [I-D.iannone-scenarios-problems-addressing], a clear problem statement is provided. "Control Options For DNS Client Proxies", Philip Homburg, 2022-07-11, The introduction of many new transport protocols for DNS in recent years (DoT, DoH, DoQ) significantly increases the complexity of DNS stub resolvers that want to support these protocols. A practical way forward is to have a DNS client proxy in the host operating system. This allows applications to communicate using Do53 and still get the privacy benefit from using more secure protocols over the internet. However, such a setup leaves the application with no control over which transport the proxy uses. This document introduces EDNS(0) options that allow a stub resolver to request certain transport and allow the proxy to report capabilities and actual transports that are available. "Advertising Redundancy Policy in BGP", Fan Yang, Xuesong Geng, Tianran Zhou, 2022-07-11, Redundancy Protection is a generalized protection mechanism by replicating and transmitting copies of flow packets on redundancy node over multiple different and disjoint paths, and further eliminating the redundant packets at merging node. In order to support the replication behavior of redundancy protection, Redundancy Policy is used to instruct the replication of service packets and assign more than one redundancy forwarding paths. This document defines the extensions to BGP to advertise the redundancy policy. "SR Policy for enhanced DetNet", Li Zhang, Xuesong Geng, Zhenbin Li, 2022-07-11, 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. "PCEP for Enhanced DetNet", Li Zhang, Xuesong Geng, Tianran Zhou, 2022-10-23, 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. "ISIS-TE Extensions for Enhanced DetNet", Xuesong Geng, Zhenbin Li, Tianran Zhou, 2022-07-11, This document defines extensions to ISIS to distribute the enhanced DetNet information at node and/or link granularity. "BGP - Link State (BGP-LS) Advertisement of IGP DetNet Extensions", Xuesong Geng, Zhenbin Li, Tianran Zhou, 2022-07-11, This document defines extensions to BGP-LS to distribute the enhanced DetNet information "IGP Extensions for Advertising Node Index", Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-07-11, 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, 2022-07-11, 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, 2022-10-16, 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. "L2VPN VPWS Seamless with EVPN VPWS over SRv6", fuzheng, Tong Zhu, renhuajun, 2022-07-11, This document provides a solution for migrating L2VPN virtual private wire service(VPWS) to Ethernet VPN Virtual Private wire service (EVPN-VPWS) over SRv6. The service provider may want to migrate L2VPN VPWS to EVPN-VPWS, and deploy EVPN-VPWS over SRv6 network. When co-existing of EVPN-VPWS over SRv6 network and a legacy L2VPN VPWS over MPLS/IP network, the next hop of the EVPN Ethernet-AD per EVI route is different from the nexthop of VPWS AD routes or the source of LDP-LM message of the legacy L2VPN VPWS. As a result, whether the pseudowire of the EVPN VPWS and legacy L2VPN VPWS is same cannot be identified by the next hop of the EVPN Ethernet-AD per EVI route and VPWS AD routes or LDM messages. This document provides a solution to identify whether the pseudowire of EVPN VPWS is same with the pseudowire of L2VPN VPWS, which allows migrating VPWS to EVPN- VPWS under the same vpn instance but over different network. "Architecture of Computing Power Optical Network", Zhengjie Sun, 4875690059616E67, Chao Li, Sheng Liu, Haomian Zheng, 2022-07-11, This document describes the architecture of computing power optical network. "Design Consideration of IPv6 Multicast Source Routing (MSR6)", Weiqiang Cheng, Gyan Mishra, Zhenbin Li, Aijun Wang, Zhuangzhuang Qin, Chi Fan, 2022-07-11, This document discusses the design consideration of IPv6 source routing multicast solution. "Distributed Learning Architecture based on Edge-cloud Collaboration", Chao Li, 4875690059616E67, Zhengjie Sun, Sheng Liu, Haomian Zheng, 2022-07-11, This document describes the distributed learning architecture based on edge-cloud collaboration. "BGP Usage for 5G Edge Computing Service Metadata", Linda Dunbar, Kausik Majumdar, Haibo Wang, Gyan Mishra, 2022-07-11, This draft describes the problems in the 5G Edge computing environment and how BGP can be used to propagating additional information, so that the ingress routers in the 5G Local Data Network can make path selection not only based on the routing distance but also the running environment of the destinations. The goal is to improve latency and performance for 5G EC services. "SCION Components Analysis", Nicola Rustignoli, Corine de Kater, 2022-08-26, SCION is an inter-domain Internet architecture that focuses on security and availability. Its fundamental functions are carried out by a number of components. This document analyzes its core components from a functionality perspective, describing their dependencies, outputs, and properties provided. The goal is to answer the following questions: * What are the main components of SCION and their dependencies? Can "Path Computation Element Communication Protocol (PCEP) Extensions to Redundancy Policy", Fan Yang, Xuesong Geng, Tianran Zhou, 2022-07-11, PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the redundancy paths computation. Specifically, two new TLVs are defined to support the request of redundancy path computation and protection method, and one TLV is defined to distribute the Candidate Path Flag of an SR Policy. "EAP defaults for devices that need to onboard", Alan DeKok, Michael Richardson, 2022-07-25, This document describes a method by which an unconfigured device can use EAP to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. First, by defining the @eap.arpa domain, and second by showing how it can be used to provide quarantined network access for onboarding unauthenticated devices. "IETF and Energy - An Overview", Toerless Eckert, Mohamed Boucadair, Pascal Thubert, Jeff Tantsura, 2022-07-11, 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 the 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. "Performance-Oriented Digital Twins for Packet and Optical Networks", Jordi Paillisse, Paul Almasan, Miquel Ferriol, Pere Barlet, Albert Cabellos, Shihan Xiao, Xiang Shi, Xiangle Cheng, Christopher Janz, Aihua Guo, Diego Perino, Diego Lopez, Antonio Pastor, 2022-10-24, This draft introduces the concept of a Network Digital Twin (NDT) for performance evaluation, a so-called Performance-Oriented Digital Twin (PODT). Two types of PODTs are described. The first, referred to as a Network Performance Digital Twin (NPDT), produces performance estimates (delay, jitter, loss) for a packet network with a specified topology, traffic demand, and routing and scheduling configuration. The second, referred to as an Optical Performance Digital Twin (OPDT), produces transmission performance estimates of an optical network with specified optical service topologies and network equipment types, topology and status. This draft also discusses interfaces to these digital twins, how these digital twins relate to existing control plane elements, and describes use cases for these digital twins, as well as possible implementation options. "Mobility challenges in virtualization environments", Carlos Bernardos, Alain Mourad, 2022-07-11, Mobility is no longer restricted to physical end systems roaming among radio points of attachment. Current mobile network deployments do not only consider the traditional client-server model, but also include scenarios in which services are decomposed into functions that run on virtualized resources, thus becoming virtual functions. This opens the door for new scenarios in which mobility now includes: (i) the end-system mobility (traditional scenario), (ii) a physical resource hosting a virtual function (part of a service being consumed by a end-system) moving, and (iii) a virtual function part of a service moving (migrating) to a different physical resource. As these scenarios are expected to be more commonly deployed in the short future, this documents aims at presenting the new mobility- related scenarios and the potential gaps in terms of IETF protocols. "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Hannes Tschofenig, Thomas Fossati, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, 2022-10-24, Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. In use cases that require the use of remote attestation, such as confidential computing or device onboarding, an attester has to convey evidence or attestation results to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing evidence and attestation results in the TLS handshake. Functionality-wise this is accomplished with the help of key attestation. "ECH for Enterprises and Organizations", Arnaud Taddei, Simon Edwards, 2022-07-11, This paper reviews some of the Enterprises and Organizations requirements and constraints and tests the current Encrypted Client Hello (ECH) proposal in these environments. In particular it highlights the need for several clarifications as well as highlights known attack vectors which will become easier with the current ECH proposal. The current ECH drafts should consider how they want to include enterprises operational security capabilities to mitigate these attacks. "Mandatory-to-Implement Algorithms for Creators and Consumers of Software Update for the Internet of Things manifests", Brendan Moran, 2022-10-24, 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. "Recursive Bitstring Structure (RBS) for Multicast Source Routing over IPv6 (MSR6)", Toerless Eckert, Xuesong Geng, Xiuli Zheng, Rui Meng, Fengkai Li, 2022-10-24, This document defines an encoding and corresponding packet processing procedures for native IPv6 multicast source routing (MSR6) using a so-called "Recursive Bitstring" (RBS) address structure. The RBS address structure encodes the source-routed multicast tree as a tree of bitstrings. Each router on the tree only needs to examine and perform replication for the one bitstring destined for it. The MSR6/RBS IPv6 extension header encoding and processing is modeled after that of unicast source routing headers, RFC6554 and RFC8754, and shares all elements that can be shared. To support the RBS structure, it is replacing the "Segments Left" pointer to the next segment with two fields to point to the next sub-tree to parse. "Green Networking Metrics", Alexander Clemm, Lijun Dong, Greg Mirsky, Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini, 2022-10-20, This document explains the need for network instrumentation that allows to assess the 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 energy efficiency and "greenness". "ALTO extensions for handling Service Functions", Luis Contreras, Sabine Randriamasy, Xufeng Liu, 2022-07-11, This document proposes the usage of ALTO (and its extensions) to provide information about service functions to clients (e.g., external systems) that could consume such information for decisions requiring network information (service composition, traffic steering to service chains, etc). "BIER Extension Headers", Zhaohui Zhang, Xiao Min, Yisong Liu, Hooman Bidgoli, 2022-07-11, 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. "Cryptographically Generated Device identifiers", Sri Gundavelli, Mark Grayson, 2022-07-11, Network Access Identifier (NAI) is an identifier used by access networks for identifying users requesting access to the network. A user may access the network using more than one device, but all using the same NAI and the associated credentials. There are various use- cases where an access network needs to unambiguously identify a device used for accessing the network, and NAI is not sufficient for such determination. This document describes a device identifier structure and also identifies the potential stable identifiers that are present on a dual-radio device which can be used as a device identifiers. This document also describes mechanisms where the device can generate device identifiers using cryptographic methods. These generated identifiers are transient in nature and are unique to a given access network. Device identifier is intended to be shared only with a trusted access network which holds the user's network access credentials and for which the identifier was generated. "A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information", Donald Eastlake, Haoyu Song, 2022-07-11, 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. "Composite KEM For Use In Internet PKI", Mike Ounsworth, John Gray, 2022-07-11, The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptanalysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious Implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected. For digital signatures, this is referred to as "dual", and for encryption key establishment this as referred to as "hybrid". This document, and its companions, defines a specific instantiation of the dual and hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. EDNOTE: the terms "dual" and "hybrid" are currently in flux. We anticipate an Informational draft to normalize terminology, and will update this draft accordingly. This document defines a Composite key encapsulation mechanism (KEM) procedure, for use with Composite keys which consist of combinations of Encryption or KEM algorithms for each composite component algorithm. This document also introduces the idea of assigning an Object Identifier (OID) to a shared secret combiner so that stronger combiners can be implemented in the future without needing to re- issue this specification. This document is intended to be coupled with the composite keys structure define in [I-D.ounsworth-pq-composite-keys] and the CMS KEM-TRANS mechanism in [I-D.perret-prat-lamps-cms-pq-kem]. "Challenges and Opportunities in Green Networking", Alexander Clemm, Cedric Westphal, Jeff Tantsura, Laurent Ciavaglia, Marie-Paule Odini, 2022-10-20, Reducing technology's carbon footprint is one of the big challenges of our age. Networks are an enabler of applications that reduce this footprint, but also contribute to this footprint substantially themselves. The biggest opportunities to reduce the energy footprint may not be networking specific, for instance general power efficiency gains in hardware or hosting of equipment in more cooling-efficient buildings. Yet methods to make networking technology itself "greener" also need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for reducing this footprint and reducing network energy demand. "IETF Network Slice Application in 3GPP 5G End-to-End Network Slice", Xuesong Geng, Luis Contreras, Reza Rokui, Jie Dong, Ivan Bykov, 2022-10-24, Network Slicing is one of the core features in 5G, which provides different network service as independent logical networks. To provide 5G network slices service, an end-to-end network slice needs to consists of 3 major types of network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of IETF network slice in providing 5G end-to-end network slices, including the network slice identification mapping, network slice parameter mapping and 5G IETF Network Slice NBI. "More Instant Messaging Interoperability (MIMI) message content", Rohan Mahy, 2022-10-24, This document describes content semantics common in Instant Messaging (IM) systems and describes an example profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. It adapts prior work (CPIM) to work well in the MLS context. "Flex-Algorithm TLV in PIM Join Attributes", BenChong Xu, Zheng Zhang, 2022-11-08, This document defines a PIM join attribute to support building multicast distribution trees flowing Flex-Algorithm path. "More Instant Messaging Interoperability (MIMI) problem outline", Rohan Mahy, 2022-10-24, Instant Messaging interoperability requirements have changed dramatically since the last IETF activity in the space. This document presents an outline of problems that need to be addressed to make possible interoperability of modern Instant Messaging systems. The goal of this problem outline is to point at more detailed drafts which spawn discussion and eventually spur the IETF standards process. "More Instant Messaging Interoperability (MIMI) Identity Concepts", Rohan Mahy, 2022-10-24, This document discusses concepts in instant messaging identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. The goal is to explore the problem space in preparation for framework and requirements documents. "Performance Measurement (PM) with Flow-ID in Bit Index Explicit Replication (BIER)", Xin Zhang, Aijun Wang, 2022-07-12, This document proposes one new performance measurement method of Bit Index Explicit Replication (BIER) IOAM information. The controller can realize the closed-loop control of end-to-end quality assurance for BIER through collecting and analyzing of BIER IOAM and related path algorithms in the new method. "Problem statement for Inter-domain Intent-aware Routing using Color", Shraddha Hegde, Dhananjaya Rao, Srihari Sangli, Swadesh Agrawal, Clarence Filsfils, Ketan Talaulikar, Keyur Patel, Jim Uttaro, Bruno Decraene, Alex Bogdanov, Luay Jalil, Andrew Alston, Xiaohu Xu, Arkadiy Gulko, Mazen Khaddam, Luis Contreras, Dirk Steinberg, Jim Guichard, Wim Henderickx, Chris Bowers, 2022-07-15, 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. "Encapsulation of MPLS Network Actions and associated Data", Jie Dong, Tianran Zhou, 2022-07-24, This document specifies a solution for carrying MPLS network actions and the associated data either in the MPLS label stack or after the MPLS label stack. "Circuit Style Segment Routing Policies", Christian Schmutzer, Clarence Filsfils, Zafar Ali, Francois Clad, Praveen Maheshwari, Reza Rokui, Andrew Stone, Luay Jalil, Shuping Peng, Tarek Saad, Dan Voyer, 2022-07-24, This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for strict bandwidth guarantees, 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). "JSON Web Proof", Jeremie Miller, David Waite, Michael Jones, 2022-07-24, The JOSE set of standards established JSON-based container formats for Keys (https://datatracker.ietf.org/doc/rfc7517/), Signatures (https://datatracker.ietf.org/doc/rfc7515/), and Encryption (https://datatracker.ietf.org/doc/rfc7516/). They also established IANA registries (https://www.iana.org/assignments/jose/jose.xhtml) 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 and support binding mechanisms. "JSON Proof Algorithms", Jeremie Miller, Michael Jones, 2022-07-24, The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) (https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof- 00.html) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. "JSON Proof Token", Jeremie Miller, Michael Jones, 2022-07-24, 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) (https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof- 00.html) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). "Issues with the SMTP/IMF 'for' Clause and Remedies", John Klensin, 2022-07-24, The "for" clause of the "Received:" header field goes back to the first widely deployed version of SMTP (RFC 821). However SMTP also allows multiple-recipient messages to be transmitted in a single mail transaction. The combination may, in some cases, lead to undesirable disclosure of information, including disclosing mail addresses that were intended to be kept hidden from other recipients. In the process of working on revisions to RFC 5321 and developing a new Applicability Statement in the EMAILCORE WG, there have been attempts to fix the problems by find-tuning text about actions and warnings. This document is an attempt to explore the issues in somewhat more depth for members of the community who are, or should be, participating in the WG. "BGP Colorful Prefix Routing (CPR) for SRv6 based Services", Haibo Wang, Jie Dong, Jingrong Xie, Xinjun Chen, 2022-07-25, This document describes a mechanism to advertise different IPv6 prefixes which are associated with different color attributes to establish end-to-end intent aware paths. Such IPv6 prefixes are called "colorful prefixes", and this mechanism is called Colorful Prefix Routing (CPR). The colorful prefixes are the SRv6 locator prefixes associated with different intent. SRv6 services (e.g. SRv6 VPN services) could be assigned with SRv6 SIDs under the SRv6 locator prefix with the required intent, so that the SRv6 service traffic can be steered to the end-to-end intent aware paths of the corresponding SRv6 locator prefix to meet the service requirements. The existing IPv6 unicast Address Family could be used for the advertisement of colorful prefixes, thus this mechanism is easy to interoperate and allows incremental deployment in multi-domain networks. "I2NSF Analytics Interface YANG Data Model", Patrick Lingga, Jaehoon Jeong, Yunchul Choi, 2022-07-25, 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). "WebRTC-HTTP Egress Protocol (WHEP)", Sergio Murillo, Chen Cheng, 2022-10-19, 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). "Video BFrame RTP Header Extension", openser, 2022-07-25, This document describes an RTP header extension used to convey decoding time information about video when Bi-directional predicted frames exist.It adds CompositionTime(CTS) as value so that receiver can decode video with correct sequence. "The "xml2rfc" version 3 Vocabulary as Implemented", John Levine, 2022-09-19, This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. "Encryption algorithm Rocca-S", Yuto Nakano, Kazuhide Fukushima, Takanori Isobe, 2022-11-05, 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). "CBOR Object Type Extension (COTX)", Anders Rundgren, 2022-12-05, This document describes a CBOR tag for providing type information to CBOR data. Unlike the native CBOR tagging scheme which builds on integer constants defined in a IANA registry, this specification supports arbitrary text based type identifiers. Such identifiers may consequently also be expressed as URLs, potentially pointing to Web pages holding related descriptions in human readable form, as well as being compatible with established methods for adding type information to JSON and XML data. "Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values", Gavin Brown, 2022-11-16, 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. "Representing IP addresses in TLS Server Name Indication (SNI)", Erik Nygren, Rich Salz, 2022-07-27, This specification provides a mechanism for clients to send IP addresses in a TLS Server Name Indication (SNI) extension as part of TLS handshakes, allowing servers to return a certificate containing that subjectAltName. This is done by converting the IP address to a special-use domain name. "A Larger Internet Key Exchange version 2 (IKEv2) Payload", Yoav Nir, 2022-07-27, 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, 2022-09-30, This obsoletes RFC 4777 with an enhanced Automatic Sign-On a password hash, recommended Telnet security considerations using TLS and update on how non-complient 5250 negotiations are handled. "Problem Satement of IPv6 Multicast Source Routing (MSR6)", Yisong Liu, Tianji Jiang, Toerless Eckert, Zhenbin Li, Gyan Mishra, Zhuangzhuang Qin, Changwang Lin, Xuesong Geng, 2022-10-21, This document analyses the gaps of the existing IPv6 multicast solutions under discussion in IETF based on the requirements. "SCIM Referential Value Location Extension", Danny Zollner, 2022-07-29, The System for Cross-domain Identity Management standard's schema RFC [RFC7643], as well as custom schemas, may have attribute values that have a finite set of acceptable values. These acceptable values are frequently tied to a value on another resource. For instance, an organization may only allow values in the Enterprise User schema's costCenter attribute that are valid identifiers of cost centers defined in another location. This draft aims to provide a way for a SCIM client to determine if an attribute in a schema is limited to a specific set of values, and where those values may be located on another SCIM resource type. "Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)", Greg Mirsky, 2022-11-17, 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. "An Unreliable Extension to QUIC", Jianping Chen, Tianyi Liu, Junxian Jing, Yongyi Yu, 2022-09-19, QUIC Unreliable (QUICU) is an extension of the QUIC protocol for unreliable data transmission, mainly through the definition and use of three new types of frames, namely the Expire Offset Frame, Boundary Frame, and Correlation Frame. The main purpose of this extension is to reduce data delivery delay. Through controlling the timing and scope of packet losses, QUICU reduces useless transmission to improve transmission efficiency, reduces head-of-line blocking to improve transmission timeliness, which are beneficial to delay- sensitive applications, especially audio and video applications. This document describes the motivation, the operations, and the wire formats of the three new types of frames. "PCAP and PCAPNG LINKTYPE Registry", Guy Harris, Michael Richardson, 2022-11-06, This document creates a 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. "Requirement of Lightweight Authentication and Key Agreement Protocols for IoT", Yaping Liu, henryzs, Zhiyu Han, 2022-07-29, This document specifies the requirement of lightweight authentication and key agreement protocols for Internet of Things (LAKAPIoT). The authentication and key agreement protocols are very crucial for IoT since it can prevent unauthorized or malicious IoT devices from accessing the network. However, most IoT devices have limited storage, computing and communication capacity. Moreover, the network archi- tecture of IoT is very different from the traditional network. Therefore, designing authentication and key agreement protocols for IoT is an essential step to ensure its security. In this draft, the requirement of lightweight authentication and key agreement protocols for IoT is proposed. "Byte Range PATCH", Austin Wright, 2022-08-02, This document specifies a media type for PATCH payloads that overwrites a specific byte range, to allow random access writes, or allow a resource to be uploaded in several segments. "DAP Interoperation Test Design", David Cook, 2022-11-05, 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. "Carrying a Generic Identifier in IPv6 packets", Justin Iurman, 2022-08-06, Some recent use cases seem to have a need for carrying IDs within packets. Two examples are _I-D.draft-ietf-6man-enhanced-vpn-vtn-id_ and _I-D.draft-li-6man-topology-id_. While they might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, which could quickly exhaust the allocation space if similar designs are proposed in the future. As an example, one might need an 8-bit ID, while another one might need a 24-bit, 32-bit, or 64-bit ID. Or, even worse, one might need a 32-bit ID in a specific context, while someone else might also need a 32-bit ID in another context. Therefore, allocating a new code point for each similar option is probably not the way to go. "RFC Format Framework As Implemented", Paul Hoffman, 2022-08-09, RFC 7990 "serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan" for the format of RFCs. The eventual implementation of the framework happened somewhat differently than was described in RFC 7990. This document describes how the framework was, and is being, implemented. "Canonical Format for RFCs", Paul Hoffman, 2022-08-09, This document updates RFC 7990 by changing the definition of the "canonical format" for RFCs. "Remove SHA-1 from active use within DNSSEC", Wes Hardaker, 2022-08-12, This document retires the use of SHA-1 within DNSSEC "The Transit Measurement Option", Tal Mizrahi, Tianran Zhou, Shahar Belkar, Reuven Cohen, 2022-08-15, 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. "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", Wes Hardaker, Paul Wouters, Ondrej Sury, 2022-09-08, The DNSSEC protocol makes use of various cryptographic algorithms in order 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 a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. "ECN Over Aggregating Tunnels", Martin Duke, 2022-08-15, Explicit Congestion Notification (ECN) provides two bits in the IP header for routers to signal congestion to endpoints without resorting to packet loss. RFC6040 provided guidance for how IP-in-IP tunnels should transfer (ECN) markings between inner and outer IP headers. However, that document implicitly assumes that no more than one inner packet is present in an outer packet. As numerous tunneling technologies have since emerged that break this assumption, further guidance is needed. "Real-Time Monitoring Link/Protocol Neighbor State", Tianran Zhou, Feng Xu, Shunwan Zhuang, Haibo Wang, 2022-08-15, 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. "Abstract next-hop addresses in IP VPNs", Igor Malyushkin, 2022-08-17, draft-malyushkin-bess-ip-vpn-abstract-next-hops-00 Abstract This document discusses the IP VPN convergence aspects and specifies procedures for IP VPN to signal the attachment circuit failure. The specified procedures help significantly improve the IP VPN convergence. 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-malyushkin-bess-ip-vpn- abstract-next-hops/. Discussion of this document takes place on the BGP Enabled ServiceS Working Group mailing list (mailto:bess@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/bess/. Subscribe at https://www.ietf.org/mailman/listinfo/bess/. "Cisco's CoAP Simple Management Protocol", Paul Duffy, 2022-11-17, 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. "Applying TCP User Timeout Parameter to BGP Sessions", Enke Chen, Robert Raszuk, 2022-08-17, In this document we discuss the TCP "User Timeout" parameter and recommend using it to handle stuck BGP sessions. "Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension", Aaron Gable, 2022-08-17, 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. Current Implementations Draft note: this section will be removed by the editor before final publication. Let's Encrypt's Staging environment (available at [lestaging], source at [boulder]) implements this draft specification. "The R5N Distributed Hash Table", Martin Schanzenbach, Christian Grothoff, Bernd Fix, 2022-08-19, This document contains the R^5N DHT technical specification. This document defines the normative wire format of resource records, resolution processes, 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. "Special-Use Domain Names Registry", Paul Hoffman, 2022-10-03, This document obsoletes RFC 6761 that created the Special-Use Domain Names registry at IANA for domain names that are reserved for special use. The registry has proved to be useful. RFC 6761 also has a description for when reserving such a name is appropriate, and the procedure for doing so; those descriptions have turned out to cause many problems in the IETF. Because of those problems, this document obsoletes RFC 6761 while retaining the registry and greatly reducing the rest of the discussion and requirements in RFC 6761. It places the responsibility for accepting Special-Use Domain Names entries with the IESG. [ A repository for this draft can be found here (https://github.com/ paulehoffman/6761bis). ] "Interoperability Procedures for BGP Routes with Color", Jeffrey Haas, 2022-08-19, "BGP Routes with Color" have become a topic of interest in the IDR Working Group. The authors of the various proposals have many things in mind to solve with them, how a color might be used, and the operational model for their solution. In general, the solutions share some core properties: Routes for an IP endpoint, that have a domain-wide semantic element to differentiate forwarding (often called a color), and appropriate state to enable that differentiated forwarding. Examples of the technologies enabling differentiated forwarding include MPLS and Segment Routing. This document examines two of the current proposals - BGP Color-Aware Routing, and BGP Classful Transport - and proposes mechanisms to permit them to interoperate. "Secure Asset Transfer (SAT) Use Cases", Venkatraman Ramakrishna, Thomas Hardjono, 2022-10-17, 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. "Kyber Post-Quantum KEM", Peter Schwabe, Bas Westerbaan, 2022-09-23, This memo specifies 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, 2022-09-15, This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar or, in some cases, identical techniques could be and have been applied to other cases. "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", Michael Tuexen, Randall Stewart, 2022-08-25, 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. "BGP Extension for 5G Edge Service Metadata", Linda Dunbar, Kausik Majumdar, Haibo Wang, Gyan Mishra, 2022-09-19, This draft describes three new sub-TLVs for egress routers to advertise the Edge Service Metadata of the directly attached edge services (ES). The Edge Service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selection 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 flows from a specific source, like specific User Equipment (UE). "SCION Control-Plane PKI", Corine de Kater, Nicola Rustignoli, 2022-08-26, This document presents the trust concept and design of the SCION _control-plane 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. The document first describes the trust model behind SCION's control- plane PKI, and provides a short overview of the certificates, keys, and roles involved. It then continues with detailed specifications of the building blocks of SCION's control-plane PKI. The document concludes with several considerations in regard to deploying the control-plane PKI. "Distributed Flow Measurement in IPv6", Haojie Wang, sijun weng, Changwang Lin, Xiao Min, 2022-10-11, 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. "An Unreliable Oblivious HTTP Extension", Ralph Giles, Christopher Wood, 2022-08-30, This document describes an extension to Oblivious HTTP (OHTTP) that supports unreliable application data transfer from Client to Target. Beyond enabling application uses that do not require explicit responses from the Target, such as privacy-preserving data collection, this extension allows the Oblivious Relay Resource to buffer, batch, and shuffle requests to Oblivious Gateway Resources as a way of amplifying end-to-end client privacy protections. "EVPN Next Hop address encoding", Mike Dubrovsky, 2022-09-03, This document clarifies that the EVPN route Next Hop encoding is unaffected by whether the underlying BGP session is IPv4 or IPv6. From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the encoding. "Reverse Traceroute", Valentin Heinrich, Rolf Winter, 2022-09-05, Only very few troubleshooting tools exist, that universally work on the public internet. Ping and traceroute are the ones that are most frequently used, when issues arise that are outside the user's administrative reach. Both perform quite basic checks. Ping can only confirm basic reachability of an interface. Traceroute can enumerate routers in the forward direction of a path but remains blind to the reverse path. In this memo, ICMP extensions are defined, that allow to build a reverse traceroute tool for the public internet. "Challenging Scenarios and Problems in Internet Addressing", Luigi Iannone, Dirk Trossen, Nirmala Shenoy, Paulo Mendes, Donald Eastlake, Peng Liu, Dino Farinacci, Jens Finkhaeuser, Yihao Jia, 2022-09-05, 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. However, domains with specific requirements as well as communication behaviors and semantics still exist and represent what [RFC8799] recognizes as "limited domains". This document describes well-recognized scenarios that showcase possibly different addressing requirements, which are challenging to be accommodated in the IP addressing model. These scenarios highlight issues related to the Internet addressing model and call for starting a discussion on a way to re-think/evolve the addressing model so to better accommodate different domain-specific requirements. The limitations identified in this document are complemented and deepened by a detailed analysis in a separate companion document [I-D.iannone-internet-addressing-considerations]. "Known issues with the IETF SVG profile", Brian Carpenter, Nevil Brownlee, 2022-09-05, This document lists a number of issues observed in practice by authors attempting to include SVG diagrams in RFCs following the profile established by RFC7996. "OpenPGP Message Format", Werner Koch, brian carlson, Ronald Tse, Derek Atkins, Daniel Gillmor, 2022-09-06, { Work in progress to update the OpenPGP specification from RFC4880 } { This version is on the Git head with rfc4880bis-10 before the great refactoring. That refactoring, dubbed crypto-refresh, basically started from scratch with lots of re-formatting and switching to a Gitlab based approach with merge requests mainly prepared in advance by one of the chairs. This was done despite that -10 was basically ready for last call after a long iterative process adding feature by feature with rough consent from the WG. Due to the IETF submission system the draft has a new name but nevertheless is the direct successor of draft-ietf-openpgp- rfc4880bis-10 } 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. "TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences", Lenny Giuliano, Chris Lenart, Rich Adam, 2022-12-02, 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 weren't possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology for content distribution. "Subliminal Messaging in Codecs (SubliMe)", Rick van Rein, 2022-09-10, The backbone for telephony consists of a digital network that is chiefly used for audio using the G.711 codec, which is also widely supported in VoIP telephony. This specification defines Subliminal Messaging as a general facility for opportunistic data exchange in the noise levels of audio codecs, with profiles for the G.711, G.722 and CLEARMODE codecs. The data exchange can be used to negotiate other codecs, UUID-identified services and call privacy/integrity. "Replay-Resistant DomainKeys Identified Mail (DKIM) Signatures", Murray Kucherawy, 2022-11-14, DomainKeys Identified Mail (DKIM) provides a digital signature mechanism for Internet messages, allowing a domain name owner to affix its domain name in a way that can be cryptographically validated. DKIM signatures protect the integrity of the message header and body only. By design, it decoupled itself from the transport and storage mechanisms used to handle messages. This gives rise to a possible replay attack, but the original DKIM specification fell short of providing a mitigation strategy. This document presents an optional method for binding a signature to a specific recipient or set of recipients so that broader replay attacks can be mitigated. "Transfer Digital Credentials Securely - Requirements", Dmitry Vinokurov, Casey Astiz, Alex Pelletier, Jean-Luc Giraud, Alexey Bulgakov, Matt Byington, Nick Sha, Manuel Gerster, 2022-11-09, This document describes the use cases necessitating the secure transfer of digital credentials, residing in a digital wallet, between two devices and defines general assumptions, requirements and the scope of the corresponding Tigress Internet-draft [Tigress-00]. "Reliable QUIC Stream Resets", Marten Seemann, 2022-09-09, QUIC ([RFC9000]) defines a RESET_STREAM frame to reset a stream. When a sender resets a stream, it stops retransmitting STREAM frames for this stream. On the receiver side, there is no guarantee that any of the data sent on that stream is delivered to the application. This document defines a new QUIC frame, the RELIABLE_RESET_STREAM frame, that resets a stream, while guaranteeing reliable delivery of stream data up to a certain byte offset. "SAVNET-based Anti-DDoS Architecture", Yong Cui, Jianping Wu, Linbo Hui, Lei Zhang, 2022-09-09, This document proposes the SAVNET-based Anti-DDoS Architecture (SADA), which can efficiently detect, mitigate, and traceback Denial- of-Service (DDoS) attacks that spoof source addresses. The SADA consists of a distributed DDoS detection mechanism based on honeynets, a multi-stage DDoS mitigation mechanism, and a suspect- based DDoS traceback mechanism. By adopting the Source Address Validation (SAV) technique of SAVNET and introducing the data plane and the control plane, the SADA makes minor changes to the SAVNET while providing major benefits. "SAVA-based Anti-DDoS Architecture", Yong Cui, Jianping Wu, Linbo Hui, Lei Zhang, 2022-09-12, This document proposes the SAVA-based Anti-DDoS Architecture (SADA), which can efficiently detect, mitigate, and traceback Denial-of- Service (DDoS) attacks that spoof source addresses. The SADA consists of a distributed DDoS detection mechanism based on honeynets, a multi-stage DDoS mitigation mechanism, and a suspect- based DDoS traceback mechanism. By adopting the Source Address Validation Architecture (SAVA) of SAVNET and introducing the data plane and the control plane, the SADA makes minor changes to the SAVA while providing major benefits. "draft-vattaparambil-iotops-poa-based-onboarding-00", Sreelakshmi, Olov Schelen, Ulf Bodin, 2022-09-13, Industrial network layer onboarding demands a technique that is efficient, scalable, and secure. In this document, we propose Power of Attorney based authorization technique as a decentralized solution for onboarding devices. This enables users such as integrators and subcontractors to onboard devices permanently or temporarily according to terms and requirements set in the PoAs. "Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle", Changwang Lin, Mengxiao Chen, Hao Li, 2022-09-13, 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 also required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle. "Enhance with RPKI and IPsec for the Source Address Validation", Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, Guozhen Dong, 2022-09-15, Packet forwarding on Internet typically takes no place with inspection of the source address. Thus malicious attacks or abnormal behavior have been launched with the spoofed source addresses. This document describes an inter-domain source address validation with RPKI (Resource Public Key Infrastructure) and IPsec (IP Security), including the motivation, tech framework, main interactive process, and optional extensions. "An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation", Ke Xu, Jianping Wu, Yangfei Guo, Benjamin Schwartz, Haiyang Wang, 2022-10-20, 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. "The Incentive Consideration for Defense Against Reflection Attacks", Lancheng Qin, Dan Li, Jianping Wu, Li Chen, Fang Gao, 2022-11-29, Source address spoofing remains a significant challenge in today's Internet. Although source address validation (SAV) mechanisms, such as ingress filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], and the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704], have been proposed for a long time, some ASes have not deployed SAV due to the problems of existing SAV mechanism, such as inaccurate validation, misaligned incentive, or other overhead concerns. This document specifically explains the misaligned incentive problem of existing SAV mechanisms and clarifies the direct incentive that a new SAV mechanism should achieve. "IMAP4 Extension for Returning Mailbox METADATA in Extended LIST", Kenneth Murchison, Bron Gondwana, 2022-09-19, 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. "An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element", Mohamed Boucadair, 2022-09-20, RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. However, that update is still problematic for interoperability because some values were deprecated since then. This document updates RFC 7125 by removing stale information from the IPFIX registry and avoiding conflicts with the authoritative TCP registry. "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge", Antonios Chariton, Amir Omidi, James Kasten, Fotis Loukos, Stanislaw Janikowski, 2022-11-10, This document specifies a new challenge type for the Automated Certificate Management Environment (ACME) protocol which allows an ACME client to respond to a domain control validation challenge presented by an ACME server with a DNS resource that is keyed by the ACME account identification. "Yang Data Model for EVPN multicast", Hongji Zhao, Yisong Liu, Xufeng Liu, Mani Panchanathan, Mahesh Sivakumar, 2022-09-21, 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. "Asserting Wireless Network Connections Using DNS Revolvers' Identities", Dan Wing, Tirumaleswar Reddy.K, 2022-11-06, This document describes how a host uses the encrypted DNS server identity to reduce an attacker's capabilities if the attacker is emulating a wireless network. "Supporting In-Situ OAM Direct Export Using MPLS Network Actions", Greg Mirsky, Mohamed Boucadair, 2022-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 in calculating 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 how MNA can be used for collecting on-path operational state and telemetry information using IOAM-DEX Option. "Loop detection for imported routes", Zhuo Yue, Guoqi Xu, Chenxi Li, HaiChao Li, 2022-09-23, Mutual route import between two IGP instances is often involved in networking solutions. However, routing loops may occur when route are imported to an instance from another and cause critical problem. This document provides a way to detect routing loop and introduces new sub-TLVs to support advertisement IPv4 and IPv6 prefix extended attribute flags and the source router ID of the router which import the route and redistribute the route. "MPLS MNA Operational Architecture", Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant, 2022-09-26, MPLS Network Action (MNA) allows MPLS packet to carry instruction and data for in-network services and functions in an MPLS network. This document describes the network operations to support MNAs and what actions an MNA capable Label Switching Router (LSR) takes when MNA is present or absent in an packet. "MPLS Label Stack Operations in Networks with MNA Incremental Deployment", Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant, 2022-09-26, MPLS Network Action (MNA) allows MPLS packet to carry instruction and data for in-network services and functions in an MPLS network. This document describes the FEC-based optimized operations on the MPLS label stack when the network is mixed with LSRs which are capable or incapable of processing MNAs. "DRIP Entity Tag (DET) Identity Management Architecture", Adam Wiethuechter, Stuart Card, Robert Moskowitz, Jim Reid, 2022-09-27, This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS technologies and practices. Discovery of DETs and their artifacts are through the existing DNS structure and methods by using FQDNs. A general overview of the interfaces required between components is described in this document with supporting documents giving technical specifications. "DRIP Provisioning Agent (DPA) Client HTTP Interface", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-27, This document defines an HTTP based interface using either JSON or CBOR for object encodings for clients to register in a DRIP Identity Management Entity (DIME). The DPA is a logical component of the DIME that handles various DRIP specific functions and is the public interface for clients that wish to register. "DRIP Information Agent (DIA) HTTP Interface", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-27, This document defines an HTTP based interface using either JSON or CBOR for object encodings for the DRIP Provisioning Agent (DPA) or Registry to insert, update or delete information from a DRIP Information Agent (DIA). JSON Web Tokens (JWTs) are used between the entities to encapsulate and authenticate the transactions. "DRIP Registry EPP Interface", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-27, This document defines extensions to the Extensible Provisioning Protocol (EPP) to support DRIP Entity Tag (DET) and its additional information registration into a DRIP Identity Management Entity (DIME). The Registry is a logically required component of a DIME that handles the various DNS functions for DRIP registration and lookup using DETs. "DRIP Registry HTTP Interface", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-27, This document defines an HTTP based interface using either JSON or CBOR for object encodings for the DRIP Registry from a DRIP Provisioning Agent (DPA) to support DRIP Entity Tag (DET) and its additional information registration into a DRIP Identity Management Entity (DIME). The Registry is a logically required component of a DIME that handles the various DNS functions for DRIP registration and lookup using DETs. "DRIP Information Agent (DIA) RDAP Interface", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-27, This document defines the RDAP interface behaviors for clients to lookup information from a DRIP Information Agent (DIA). "Traffic Shaping Solutions for Bounded Latency in Large-scale Networks", Guoyu Peng, Shou Wang, czp@h3c.com, Lei Zhou, Peng Liu, 2022-09-28, This document presents a traffic shaping solution for DetNet service with bounded latency in large-scale networks. The traffic shaping solution includes the edge access control, enqueue cycle mapping and jitter compression mechanisms. These mechanisms support appropriate resource reservation algorithms, reasonably calculate the end-to-end delay in DetNet IP network in advance, and adjust, manage and control the resources after real-time detection. Using the traffic shaping solution, it is possible for an implementer, user, or standards development organization to realize bounded delay based on the existing TSN/DetNet queuing models. "The Requirements for Secure Routing", chenmeiling, Li Su, 2022-09-28, At present, the routing process is to look up its own routing table through the router to realize packet forwarding or data discarding. With the development of the network, attention is paid not only to reachability but also to security capability in the routing process. With the frequent occurrence of security incidents, more and more network devices have security functions, secure routing and secure path is required by many scenarios. "YANG Data Models for Attacks Intelligent Detection", Weilin Wang, Hua-chun Zhou, Man Li, Qi Guo, Shuangxing Deng, 2022-09-29, This document describes how to extend the Interface to Network Security Function (I2NSF) framework to make it suitable for attacks intelligent detection. Intelligent detection means that the network can dynamically adjust detection policies based on resource status, traffic features, or detection results. This document describes the application of I2NSF Framework for Security Management Automation (SMA) for attacks intelligent detection in Software-Defined Networking (SDN) and Service Function Chaining (SFC) environment. This document will extend the YANG data model of Monitoring Interface, Analytics Interface and NSF-Facing Interface in I2NSF for SMA framework to make it suitable for attacks intelligent detection in SDN and SFC environments. "Deep Dive into IPv6 Extension Header Testing", Nalini Elkins, michael ackermann, Dhruv Dhody, 2022-10-21, IPv6 Extension Header testing is a complex area. Studies have shown varying results. This document proposes a methodology for isolating the location and reasons for IPv6 Extension Headers blockage. This document outlines the basic framework and set of documents which will follow. "Transfer Digital Credentials Securely", Dmitry Vinokurov, Matt Byington, Matthias Lerch, Alex Pelletier, Nick Sha, 2022-11-09, This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information. "The WebRTC URI Scheme", Jiang,Jianxing, 2022-10-17, This document registers the "wr://" and "wrs://" URI schemes to aid in the connect of WebRTC. "Replay Resistant Authenticated Receiver Chain", Wei Chuang, Allen Robin, 2022-10-21, 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 (https://www.rfc- editor.org/rfc/rfc6376.html#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 two Replay Resistant cryptographic domain based protocols that leverage ARC [RFC8617]. The first technique discloses all SMTP recipients as signed RFC822 headers by the sender which allows a receiver to verify this. The second technique defines a SMTP extension that allows both the sender and receiver to participate in signing the message signature. It includes a path building technique that accurately defines the SMTP forwarding path of the message. Both techniques permit a receiver to detect DKIM and ARC replay. "draft-vattaparambil-irtf-dinrg-poa-00", Sreelakshmi, Olov Schelen, Ulf Bodin, 2022-10-04, 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 for example with semi autonomous devices to have them act on behalf. 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. As an example in this document we explain Power of Attorney based authorization technique as a decentralized solution for onboarding devices. Industrial network layer onboarding demands a technique that is efficient, scalable, and secure. PoA based onboarding enables users such as integrators and subcontractors to onboard devices permanently or temporarily according to terms and requirements set in the PoAs. "DKIM Envelope Validation Extension (eve)", Marc Bradshaw, 2022-10-04, DKIM as defined in RFC6376 is an IETF standard of cryptographically signing email with a domain key. DKIM is widely used to build a reputation based on the signing domain and assign that reputation to message filtering. Section 8.6 defines a vulnerability called DKIM replay, in which a single message can be replayed to a large group of unrelated recipients, thereby hijacking the reputation of the original sender. This proposal defines a method of declaring the original envelope sender and recipient(s) within a DKIM signature such that compliant DKIM validators can detect a DKIM signature which may have been replayed and modify their use of domain reputation accordingly. This technique remains fully backwards compatible with DKIM validators which do not support the new methods, while allowing compliant forwarders to declare their ingress authentication state in Authentication Results headers for consumption by subsequent validators. "Deprecating RADIUS/UDP and RADIUS/TCP", Alan DeKok, 2022-10-04, 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 the use of the User Datagram Protocol (UDP) and of the Transport Congestion Protocol (TCP) as transport protocols for RADIUS. These transports are permitted inside of secure networks, but their use even in that environment is strongly discouraged. For all other environments, the use of TLS- based transports is mandated. "Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server", Nalini Elkins, michael ackermann, Dhruv Dhody, 2022-10-05, This document proposes a methodology for isolating the location and reasons for IPv6 Extension Headers blockage in a network where the operator has access to install products and run diagnostic tests on both the client and server. Neither the client nor the server should be behind a CDN or on a Cloud infrastructure. This document is a part of the Deep Dive into EH Testing set of documents. "IPv6 only iterative resolver utilising NAT64", Momoka Yamamoto, Toyota Yasunobu, 2022-10-05, By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers can operate in an IPv6-only environment. When a specific DNS zone is only served by an IPv4-only authoritative server, the iterative resolver will translate the IPv4 address to IPv6 to access the authoritative server's IPv4 address via NAT64. This mechanism allows IPv6-only iterative resolvers to initiate communications to IPv4-only authoritative servers. "Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets", Toerless Eckert, Stewart Bryant, Andrew Malis, Guangpeng Li, 2022-11-06, This memo specifies a forwarding method for bounded latency for Deterministic Networks. It uses cycle tagging of packets for cyclic queuing and forwarding with multiple buffers (TCQF). This memo standardizes tagging via the MPLS packet Traffic Class (TC) field for MPLS links and the IP/IPv6 DSCPfield for IP/IPv6 links. The short- hand for this mechanism is Tagged Cyclic Queuing and Forwarding (TCQF). 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. "RDAP RIR Search", Tom Harrison, Jasdip Singh, 2022-10-05, 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. "SASL Authentication for SIP", Rick van Rein, 2022-10-14, Many protocols benefit from "pluggable" authentication choice as a result of SASL authentication. In the Session Initiation Protocol, the independent branch of HTTP Authentication has been elected. Recent progress has been made in bringing SASL to HTTP, but SIP has its own special considerations and needs its own embedding to gain the flexibility of SASL. "A SASL and GSS-API Mechanism family using the asymmetric password-authenticated key agreement OPAQUE", Nadja von Reitzenstein Cerpnjak, 2022-10-06, This specification describes a family of Simple Authentication and Security Layer (SASL, RFC4422) authentication mechanisms based on the OPAQUE asymmetric password-authenticated key agreement (PAKE) algorithm. They offer two distinct advantages over the SCRAM family of mechanisms. The underlying OPAQUE algorithm provides the ability for clients to register without the servers getting access to the clear text password of an user, preventing password exfiltration at registration. Secondly a successful authentication produces a long- term secret key only known to the client that can be used to access encrypted server-side data without needing to share keys between clients via a side-band mechanism. When used in combination with TLS or an equivalent security layer these mechanisms allow for secure channel binding. "PCEPS with TLS 1.3", Dhruv Dhody, Sean Turner, Russ Housley, 2022-10-20, RFC 8253 defines how to protect PCEP messages with TLS 1.2. This document describes how to protect PCEP messages with TLS 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Path Computation Element Working Group mailing list (pce@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/pce/. Source for this draft and an issue tracker can be found at https://github.com/dhruvdhody/draft-dhody-pce-pceps-tls13. "Email extension for specifying the next hop path for delivery", Bron Gondwana, 2022-10-10, Much work has been put into adding authentication methods (DKIM, ARC), source verification (SPF) and policy support (DMARC) to email flows, however all these specifications have focused on looking backwards through email flow only, and only add new headers to messages, causing them all to be susceptible to replay or re-use. In particular, in early 2022, a type of attack called "DKIM Replay" was widely seen, where correctly DKIM-signed messages were sent to a different envelope sender. The "To" address would not be aligned, but such messages can also be the result of legitimate mailflow, so these messages were delivered to end-recipient mailboxes, and caused reputation issues for the signers of the original message. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters, 2022-10-07, 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 deprecate assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option). "the Description and Definition for Atomic Security Functions", chenmeiling, Li Su, 2022-10-07, At present, many security products are deployed in the network, and the security functions of security products overlap. Atomized security function refers to the smallest representation unit of security function, which cannot be split again and can be implemented by independent code. Atomized security functions can quickly and effectively assemble security capabilities and provide security services. It no longer takes security products as the unit, but atomic security functions as the basic unit, by reorganize and define the security functions supported by existing network devices then provide guidance for secure routing, finally, each security function will be uniformly coded. "Purchase Exchange Format (PEF)", Maximilian Frank, 2022-10-08, This document defines the purchase exchange format (PEF), which consists of signed purchase records, to enable sharing, verification, and transfer of information about license ownership. This enables sharing of abonnements, rentals, and one-time-purchases across platforms as well as deleting or switching accounts of (media) service providers without loosing or double-purchasing products. It can also be applied to non-media products. "DKIM Key Wrapper Format", Steven Jones, Nicola Selenu, 2022-10-10, This experimental RFC seeks to document a DKIM key interchange format intended to avoid provisioning errors where different parties are generating keys and publishing DNS records for a given domain. "IPv6 Neighbor Discovery Prefix Registration", Pascal Thubert, 2022-10-14, This document updates RFC 8505 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-independant interface for the node to request neighbor router(s) to redistribute the prefix to the larger routing domain using their specific routing protocols. As an example, this document extends RFC 9010 to enable the 6LR to inject the registered prefix in RPL. "In-band Task Provisioning for DAP", Shan Wang, Christopher Patton, 2022-11-16, An extension for the Distributed Aggregation Protocol (DAP) is specified that allows the task configuration to be provisioned in- band. "RATS Conceptual Messages Wrapper", Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, 2022-10-20, This document defines two encapsulation formats for RATS conceptual messages (i.e., evidence, attestation results, endorsements and reference values.) The first format uses a CBOR or JSON array with two members: one for the type, another for the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. "NETCONF Extension to support Trace Context propagation", Roque Gagliano, Kristian Larsson, Jan Lindblad, 2022-10-12, 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. "The Hypertext Transfer Protocol Attestable (HTTPA) Version 2", Hans Wang, Gordon King, Nick Li, Ned Smith, Krzysztof Sandowicz, 2022-10-18, 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. "HTTP Unprompted Authentication", David Schinazi, David Oliver, Jonathan Hoyland, 2022-10-13, Existing HTTP authentication mechanisms 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 schemes (such as signatures or message authentication codes) 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. "Secure RADIUS", Alan DeKok, 2022-10-13, This document defines Secure RADIUS (SRADIUS), which is a transport profile for RADIUS. There are three changes from traditional RADIUS transport protocols. First, TLS transport is required and insecure transports are forbidden. Second, the shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are therefore no longer necessary. Finally, the now unused Authenticator field is repurposed to contain an explict request / response identifier, called a Token. SRADIUS connections can transport all RADIUS attributes. Implementation of SRADIUS requires only minor changes to packet encoder and decoder functionality. Nothing else is changed from traditional RADIUS. "A Blockchain Trusted Protocol for Intelligent Communication Network", Zhe Tu, Hua-chun Zhou, Kun Li, Haoxiang Song, Yuzheng Yang, 2022-10-13, This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. "Additional addresses for QUIC", Maxime Piraux, Olivier Bonaventure, 2022-10-14, This document specifies a QUIC Transport Parameter 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, 2022-10-14, 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. "Modernizing HTTP Forward Proxy Functionality", Benjamin Schwartz, 2022-10-14, HTTP proxying features have long been part of the core HTTP specification. However, the core proxying functionality has several important deficiencies in modern HTTP environments. This specification defines alternative proxy service configurations for HTTP requests and TCP connections. These services are identified by URI Templates and designed for parallelism with DoH, MASQUE, and Oblivious HTTP. "The Incident Detection Message Exchange Format version 2 (IDMEFv2)", Gilles Lehmann, Thomas Andrejak, Francois Poirotte, 2022-10-15, The Incident Detection Message Exchange Format version 2 (IDMEFv2) provides a way to describe any 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 describe cyber and physical potential threats (CTI/PTI). 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 on critical infrastructures. If approved this draft will obsolete RFC4765. "Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS", Francois Poirotte, Thomas Andrejak, Gilles Lehmann, 2022-10-15, The Incident Detection Message Exchange Format version 2 (IDMEFv2) provides a way to describe any 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 describe cyber and physical potential threats (CTI/PTI). IDMEF 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 on critical infrastructures. If approved this document would obsolete RFC4767. "Views and View Addresses for Secure Asset Transfer", Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Krishnasuri Narayanam, 2022-10-16, 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. "Service Affinity Solution for TCP based Application in Anycast Situation", Wei Wang, Aijun Wang, 2022-10-17, This draft proposes a service affinity solution between client and server based on the newly defined TCP Option. 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 power resources in the distributed computing power network scenario, so as to realize the reasonable operation of cloud network resources. "Protocol for Requesting and Sharing Views across Networks", Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy, 2022-10-17, 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. "Bundle Protocol Expected Convergence Layer Adapter Services", Brian Sipos, 2022-10-17, This document attempts to harmonize the services expected of a Convergence Layer Adapter (CLA) by an overlaying Bundle Protocol Agent (BPA). This harmonization is based on combining the various existing CLA behaviors into a set of minimum expected service interfaces. "Cookies Having Independent Partitioned State specification", Dylan Cutler, 2022-11-10, This document updates RFC6265bis, defining a new attribute, Partitioned, which restricts the contexts in which a cookie is available to only those whose top-level document is same-site with the top-level document that initiated the request that created the cookie. These cookies are referred to as "partitioned cookies" and allow embedded sites which are cross-site with the top-level frame to have access to HTTP state which cannot be used for tracking across multiple top-level sites. "Interactive Authentication of Non-Interactive HTTP Requests", Benjamin Schwartz, 2022-10-17, On the World Wide Web, a rich ecosystem of authentication options has been developed to support access control for HTTP resources. However, non-interactive usage of HTTP remains limited to the simple authentication mechanisms defined in the HTTP standards. This specification allows non-interactive HTTP contexts to open a browser- like authentication context when necessary, and close it when authentication is complete. "Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework", Marc Blanchet, 2022-10-17, The current Bundle Protocol specifications define the syntax of service identifiers but do not identify how to make them interoperable. For example, there are currently no way to map a service identifier to a specific Bundle payload format for an application agent. This document proposes an application framework enabling interoperable implementations and deployments of the Bundle Protocol. It also creates a service identifier registry for the Bundle Protocol. Warning: this draft was initially done in 2012 against RFC5050 in DTNRG; some parts may need to be updated. "Inband Telemetry for HPCC++", Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Yuval Shpigelman, Jeff Tantsura, Guy Caspary, 2022-10-18, 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. "Mappings Between XML2RFC v3 and AsciiDoc", Marc Petit-Huguenin, 2022-10-18, 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. "HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Yuval Shpigelman, Jeff Tantsura, Guy Caspary, 2022-10-18, 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. "A Concise Binary Object Representation (CBOR) of DNS Messages", Martine Lenders, Thomas Schmidt, Matthias Waehlisch, 2022-10-24, This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC7049]. The primary purpose is to keep DNS messages small in constrained networks. "MPLS Network Action for Entropy", Tony Li, John Drake, 2022-10-18, Load balancing is a powerful tool for engineering traffic across a network and has been successfully used in MPLS as described in "The Use of Entropy Labels in MPLS Forwarding". With the emergence of MPLS Network Actions (MNA), there is signficant benefit in being able to invoke the same load balancing capabilities within the more general MNA infrastructure. This document describes a network action for entropy to be used in conjunction with [I-D.jags-mpls-mna-hdr]. "Analysis for the Differences Between Standard Congestion Control Schemes", Yoshifumi Nishida, 2022-11-09, Reno-based congestion control has been referred as the standard document from IETF for long time that describes congestion control principle of the Internet. In the meantime, IETF recently has published two new congestion control standards that use slightly different schemes from the previous one. This document provides analysis for the differences between these standards in order to provide helpful information when an unified congestion control principles for the Internet is standardized in the future. "Cross-Device Flows: Security Best Current Practice", Pieter Kasselman, Daniel Fett, Filip Skokan, 2022-11-21, This document describes threats against cross-device flows along with near term mitigations, protocol selection guidance and the analytical tools needed to evaluate the effectiveness of these mitigations. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. "CDDL 2.0 -- a draft plan", Carsten Bormann, 2022-10-19, 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. What specific documents spawn from the present one or whether this document is evolved into a single CDDL 2.0 specification. "The Relationship between the IETF and its Trust", Lars Eggert, Russ Housley, 2022-10-19, This document describes the expectations the IETF community has on the structure and operation of the IETF Trust. "Lightweight Authorization for EDHOC", Goeran Selander, John Mattsson, Malisa Vucinic, Michael Richardson, Aurelio Schellenbaum, 2022-10-19, This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC with third party assisted authorization, targeting constrained IoT deployments (RFC 7228). "IP Payload Compression excluding transport layer", Cheng Li, Hang Shi, Meng Zhang, Xiaobo Ding, 2022-10-19, IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase the communication performance. The IPComp is applied to payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and starting with 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. "Group Policy ID BGP Extended Community", Wen Lin, John Drake, 2022-11-08, Group Based Policy can be used to achieve micro or macro segmentation of the user traffic. For Group Based Policy, a Group Policy ID, as 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 route advertisement in the control plane. This is to facilitate policy enforcement at the ingress node when the optimization of network bandwidth is desired. "External Transaction ID for Configuration Tracing", Jean Quilbeuf, Benoit Claise, Thomas Graf, Diego Lopez, Sun Qiong, 2022-10-20, Network equipments are often configured by a variety of network management systems (NMS), protocols, and people. If a network issue arises because of a wrong configuration modification, it's important to quickly identify the specific service request and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMS's with overlapping intent, each having their own tasks to perform: in such a case, it's important to map the respective modifications to its originating NMS. This document specifies a mechanism to automatically map the configuration modifications to their source, up to a specific NMS service request, in the context of NETCONF. Such a mechanism is required for autonomous networks, to trace the reason of a particular configuration change that lead to an anomaly detection or a broken SLA. This mechanism facilitates the troubleshooting, the post mortem analysis, and in the end the closed loop automation required for self-healing networks. The specifications contain a new YANG module mapping a local configuration change to the corresponding northbound transaction, up to the controller or even the orchestrator. "Support of Versioning in YANG Notifications Subscription", Thomas Graf, Benoit Claise, Alex Feng, 2022-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 new metadata of the YANG push update notification header is proposed. "Export of On-Path Delay in IPFIX", Thomas Graf, Benoit Claise, Alex Feng, 2022-10-20, 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. "Media Header Extensions for Wireless Networks", John Kaippallimalil, Sri Gundavelli, 2022-10-20, 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. Media applications on the other hand demand both high throughput and low latency, and are able to dynamically adjust the size and quality of a stream to match available network bandwidth. However, catering to such media flows over a radio link where the capacity changes rapidly requires the buffers to be managed carefully. This draft proposes additional information about the media transported in each packet to manage the buffers and optimize the scheduling of radio resources. The set of information proposed here includes relative importance of the packet, burst length and timestamp to be conveyed by the media application in a header extension. This can be used to provide the wireless network the flexibility to prioritize packets that are essential when the radio capacity is temporarily low, defer packets that can tolerate some additional delay, or even drop packets selectively in more extreme conditions. Another aspect considered here is the means by which the media packet information is transported. Potential solutions include carrying this information in Media over QUIC extension headers, UDP options, or in a MASQUE encapsulation between the application server and wireless network entity. "NTRU Key Encapsulation", Scott Fluhrer, Michael Prorock, Sofia Celi, John Gray, 2022-10-20, This draft documents NTRU as a post-quantum Key Encapsulation Mechanism (KEM) scheme. The NTRU method from KEM is believed to be IPR free and cryptographically sound for both classical and post- quantum threat environments. NIST has run a competition to select post-quantum primitives and preliminary selected Kyber for standarization as a KEM. Kyber unfortunately has plausible patent claims against it and there are currently undisclosed agreements with the patent holders and NIST. It is unknown whether those agreements would be universally acceptable; if not, there will be organizations for which Kyber is unusable until the patents expire. This lack of clarity around licensing or other restrictions on Kyber has provided the motivation to author this draft. This document does not define any new cryptography, only describes an existing cryptographic system. "The JSON format for vCon - Conversation Data Container", Daniel Petrie, Thomas McCarthy-Howe, 2022-10-20, 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]) "Reverse CoA in RADIUS", Alan DeKok, Vadim Cargatser, 2022-10-20, 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. "Problem statement of Inter-domain Traffic Redirection Risks", Weiqiang Cheng, Dan Li, Mingqing Huang, Fang Gao, Shuanglong Chen, 2022-10-24, Redirection of network traffic on the Internet is a common technology. In operator network, there are complex scenarios, such as multi-domain interconnection and large scale network topology. Typo, limitation of out-of-band tool capabilities for configuration verification, network adjustment or failure may cause risks, such as traffic detour, traffic exposure, traffic black hole and traffic loops. This draft describes these risks. "DKIM Replay Problem Statement and Scenarios", Wei Chuang, Allen Robin, Bron Gondwana, 2022-10-20, DKIM [RFC6376] is an IETF standard for the cryptographic protocol to sign and authenticate email at the domain level and protect the integrity of messages during transit. In particular this enables DKIM to be able authenticate email through email forwarding. Section 8.6 of [RFC6376] 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. This document defines the damage this causes to email delivery and interoperability, and the impacted mail flows. Part of the reason why this is such a difficult problem is that receivers have a hard time differentiating between legitimate forwarding flows and DKIM replay. "Problems and Requirements of Addressing in Integrated Space-Terrestrial Network", Yuanjie Li, Hewu Li, Lixin Liu, Qian Wu, Jun Liu, 2022-10-21, This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. "Design Space Analysis of MoQ", Hang Shi, Yong Cui, 2022-10-21, 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. "Advertising Unreachable Links in OSPF", Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Ran Chen, Yanrong Liang, 2022-10-21, This document proposes the method to advertise unreachable links in OSPF. "Segment Encoding and Procedures For Multicast VPN Service in Native IPv6 Network", Wei Wang, Aijun Wang, 2022-10-21, This draft defines a new segment type for Multicast VPN, which contains the information of VPN customer. This segment type can be used for customer traffic differentiation by destination address on egress PEs, and assures the source and destination address not changed during the transmission. "LSP Ping/Traceroute for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, 2022-10-21, 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. "Challenges for the Internet Routing Systems Introduced by Semantic Networking", Daniel King, Adrian Farrel, Christian Jacquenet, 2022-10-21, Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols were developed based on the assumption that a destination address had this semantic. Over time, routing decisions have been enhanced to determine paths on which packets could be forwarded according to additional information carried principally within the packet headers, and dependent on policy coded in, configured at, or signaled to the routers. Many proposals have been made to add semantics to IP packets by placing additional information into existing fields, by adding semantics to IP addresses, or by adding fields to the packets. The intent is always to facilitate routing decisions based on these additional semantics in order to provide differentiated paths to enable forwarding of different packet flows on paths that may be distinct from those derived by shortest path first or path vector routing. We call this approach "Semantic Networking". This document describes the challenges to the existing routing system that are introduced by Semantic Networking. It then summarizes the opportunities for research into new or modified routing and forwarding approaches that make use of additional semantics. This document is presented as a study to support further research into clarifying and understanding the issues. It does not pass comment on the advisability or practicality of any of the proposals and does not define any technical solutions. "An Introduction to Semantic Networking", Adrian Farrel, Daniel King, 2022-10-21, Many proposals have been made to add semantics to IP packets by placing additional information in existing fields, by adding semantics to IP addresses themselves, or by adding fields. The intent is to facilitate enhanced routing/forwarding decisions based on these additional semantics to provide differentiated forwarding paths for different packet flows distinct from simple shortest path first routing. The process is defined as Semantic Networking. This document provides a brief introduction to Semantic Networking. "Encapsulation of BFD for SRv6 Policy", Yisong Liu, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Xiao Min, 2022-10-21, 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, which can be applied for both S-BFD and U-BFD. The BFD packets may be encapsulated in transport mode or tunnel mode. "Forward Erasure Correction for QUIC loss recovery", Francois Michel, Olivier Bonaventure, 2022-10-21, This documents lays down the QUIC protocol design considerations needed for QUIC to apply Forward Erasure Correction on the data sent through the network. "NETCONF Private Candidates", James Cumming, Robert Wills, 2022-10-21, This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) 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 protocol and the methods to identify and resolve conflicts between clients. "An EAT-based Key Attestation Token", Mathias Brossard, Thomas Fossati, Hannes Tschofenig, 2022-10-21, This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT) format. 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. "Automatic Extended Route Optimization (AERO)", Fred Templin, 2022-12-06, 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 to aviation, intelligent transportation systems, mobile end user devices and many other applications. "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, 2022-12-06, 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 that also applies 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. "MPLS Network Actions for No Further Fast Reroute", Tarek Saad, Israel Meilik, Tony Li, John Drake, 2022-10-21, Protection switching for MPLS traffic was first introduced in "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". Since then, Fast Reroute (FRR) has been successfully used in many MPLS networks to help ensure high availability in the face of failures. If there are multiple failures in a network, t