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 2021-10-22 04:07:47 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, Dongkyun Kim, JinHyeock Choi, 2020-08-23, 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 Mesh over BLUETOOTH(R) Low Energy using IPSP", Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk, 2021-04-22, RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth Low Energy links established by using the Bluetooth Internet Protocol Support Profile. This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links. "IPv6 over Constrained Node Networks (6lo) Applicability & Use cases", Yong-Geun Hong, Carles Gomez, Abdur Sangi, Samita Chakrabarti, 2021-07-12, 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, 2021-04-20, 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 inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and 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 Maintenance (6man) ----------------------- "Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)", Zafar Ali, Clarence Filsfils, Satoru Matsushima, Dan Voyer, Mach Chen, 2021-06-02, This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in an SRv6 network. The document also specifies the OAM flag in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. "IPv6 Minimum Path MTU Hop-by-Hop Option", Robert Hinden, Gorry Fairhurst, 2021-09-30, This document specifies a new IPv6 Hop-by-Hop option that is used to record the minimum Path MTU along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the option. "IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fengwei Qin, Ran Pang, 2021-10-21, This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode Alternate Marking information in both the Hop-by-Hop Options Header and Destination Options Header. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2021-08-29, This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz, 2021-06-04, This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. "OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework", Francesca Palombini, Ludwig Seitz, Goeran Selander, Martin Gunnarsson, 2021-05-06, This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. "EST over secure CoAP (EST-coaps)", Peter van der Stok, Panos Kampanakis, Michael Richardson, Shahid Raza, 2020-01-06, Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", Ludwig Seitz, 2021-09-07, This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server uses to authenticate to the client. "Key Provisioning for Group Communication using ACE", Francesca Palombini, Marco Tiloca, 2021-07-12, This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. 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/ace-wg/ace-key-groupcomm. "Key Management for OSCORE Groups in ACE", Marco Tiloca, Jiye Park, Francesca Palombini, 2021-07-12, 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 secured with Group Object Security for Constrained RESTful Environments (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, 2021-05-11, 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. "Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE)", Francesca Palombini, Cigdem Sengul, 2021-06-30, This specification defines an application profile for authentication and authorization for publishers and subscribers in a constrained pub-sub scenario, using the ACE framework. This profile relies on transport layer or application layer security to authorize the pub- sub clients to the broker. Moreover, it describes application layer security for publisher-subscriber communication going through the broker. "An Authorization Information Format (AIF) for ACE", Carsten Bormann, 2021-06-24, Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. To transfer detailed authorization information from an authorization manager (such as an ACE-OAuth Authorization Server) to a device, a compact representation format is needed. This document provides a suggestion for such a format, the Authorization Information Format (AIF). AIF is defined both as a general structure that can be used for many different applications and as a specific refinement that describes REST resources (potentially dynamically created) and the permissions on them. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, 2021-07-12, 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, 2021-10-01, This document specifies the use of Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). 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, 2021-07-26, 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 primer goals is to authenticate a CoAP-enabled device (EAP peer) that intends to join a security domain managed by a domain Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. This document also provides guidelines on how to generate key material for other types of security associations. Automated Certificate Management Environment (acme) --------------------------------------------------- "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock, Mary Barnes, Jon Peterson, 2021-03-27, 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, 2021-07-12, 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 End User Client and Code Signing Certificates", Kathleen Moriarty, 2021-09-29, Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support end user client, device client, and code signing certificates. "ACME Integrations", Owen Friel, Richard Barnes, Rifaat Shekh-Yusef, Michael Richardson, 2021-06-23, 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, 2021-10-13, 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". Adaptive DNS Discovery (add) ---------------------------- "Discovery of Designated Resolvers", Tommy Pauly, Eric Kinnear, Christopher Wood, Patrick McManus, Tommy Jensen, 2021-10-01, 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. 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 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 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, 2021-05-17, The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS servers. "Service Binding Mapping for DNS Servers", Benjamin Schwartz, 2021-10-21, The SVCB DNS 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 new transport protocols. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Performance Cost Metrics", Qin WU, Y. Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, Luis Contreras, 2021-10-18, Cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (i.e., the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request to determine the resource provider that offers better delay performance, the base protocol does not define the cost metric to be used. This document addresses the issue by introducing network performance metrics, including network delay, 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. "ALTO Extension: Path Vector", Kai Gao, Young Lee, Sabine Randriamasy, Y. Yang, Jingxuan Zhang, 2021-10-18, This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO Cost Map service and ALTO Property Map service so that the application can decide which endpoint(s) to connect based on not only numerical/ordinal cost values but also details of the paths. This is useful for applications whose performance is impacted by specified components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called Abstract Network Element (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Y. Yang, Kevin Ma, Jon Peterson, Jingxuan Zhang, 2021-01-12, The Content Delivery Networks Interconnection (CDNI) framework defines a set of protocols to interconnect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI described in CDNI framework is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. This document defines an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol, following the guidelines defined in RFC 8008. "ALTO Extension: Entity Property Maps", Wendy Roome, Sabine Randriamasy, Y. Yang, Jingxuan Zhang, Kai Gao, 2021-08-12, This document extends the base Application-Layer Traffic Optimization (ALTO) Protocol by generalizing the concept of "endpoint properties" to entities defined by a wide set of objects, instead of only IP addresses. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. The protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "Constrained Voucher Artifacts for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk, 2021-07-25, This document defines a protocol to securely assign a Pledge to an owner and to enroll it into the owner's network. The protocol uses an artifact that is signed by the Pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366] and [BRSKI], but defines an encoding of the voucher in CBOR rather than JSON, and enables the Pledge to perform its transactions using CoAP rather than HTTPS. The use of Raw Public Keys instead of X.509 certificates for security operations is also explained. "Information Distribution over GRASP", Xun Xiao, Bing Liu, Artur Hecker, Sheng Jiang, Brian Carpenter, 2021-07-12, 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 ([I-D.ietf-anima-grasp]) extensions as a protocol on the wire. "Support of asynchronous Enrollment in BRSKI (BRSKI-AE)", Steffen Fries, Hendrik Brockhaus, Eliot Lear, Thomas Werner, 2021-06-24, This document describes enhancements of bootstrapping a remote secure key infrastructure (BRSKI, [RFC8995] ) to also operate in domains featuring no or only timely limited connectivity between involved components. Further enhancements are provided to perform the BRSKI approach in environments, in which the role of the pledge changes from a client to a server . This changes the interaction model from a pledge-initiator-mode to a pledge-responder-mode. To support both use cases, BRSKI-AE relies on the exchange of authenticated self- contained objects (signature-wrapped objects) also for requesting and distributing of domain specific device certificates. The defined approach is agnostic regarding the utilized enrollment protocol allowing the application of existing and potentially new certificate management protocols. "Guidelines for Autonomic Service Agents", Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre, 2021-09-12, This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane and the Generic Autonomic Signaling Protocol constitute base elements of a so-called autonomic networks ecosystem. "Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2021-10-18, This document defines a protocol to securely assign a Pledge to a domain, represented by a Registrar, using an intermediary node between Pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". This document extends the work of [RFC8995] by replacing the Circuit- proxy between Pledge and Registrar by a stateless/stateful constrained (CoAP) Join Proxy. It relays join traffic from the Pledge to the Registrar. "Delegated Authority for Bootstrap Voucher Artifacts", Michael Richardson, Wei Pan, 2021-06-14, 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, 2021-10-17, This document specifies the behaviour 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", Michael Richardson, Thomas Werner, 2021-07-25, 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 better support use-cases in which JOSE is preferred over CMS. In addition to explaining how the format is created, MIME types are registered and examples are provided. 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. "IDNA2008 and Unicode 12.0.0", Patrik Faltstrom, 2021-10-03, This document describes the changes between Unicode 6.2.0 and Unicode 12.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consisstent with Unicode 12.0.0. To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008. TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC: This document is discussed on the i18n-discuss@ietf.org mailing list of the IETF. "Robots Exclusion Protocol", Martijn Koster, Gary Illyes, Henner Zeller, Lizzi Harvey, 2021-06-05, This document specifies and extends the "Robots Exclusion Protocol" [1] method originally defined by Martijn Koster in 1996 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers. "WebP Image Format Media Type Registration", James Zern, 2021-10-02, WebP is a RIFF-based image file format which supports lossless and lossy compression as well as alpha (transparency) and animation. It covers use cases similar to JPEG, PNG and GIF. Automatic SIP trunking And Peering (asap) ----------------------------------------- "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2021-06-07, 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. 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, 2021-07-12, 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 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. // 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 (-07) has a few // editorial improvements over -06, which was discussed at the ASDF // interim meeting on 2021-06-02. 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. "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Sebastien Lugan, Antonin Descampe, Corentin Damman, Thomas Richter, Tim Bruylants, 2021-07-28, This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates, while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame. "RTP Payload Format for Versatile Video Coding (VVC)", Shuai Zhao, Stephan Wenger, Yago Sanchez, Ye-Kui Wang, 2021-07-09, 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, 2021-05-23, 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, 2021-07-10, 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 proposes a new mechanism to completely encrypt header extensions and CSRCs as well a simpler signaling mechanism intended to facilitate deployment. 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. "IPv4 routes with an IPv6 next hop in the Babel routing protocol", Juliusz Chroboczek, 2021-06-18, This document defines an extension to the Babel routing protocol that allows annoncing routes to an IPv4 prefix with an IPv6 next-hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. This document updates RFC 8966. BGP Enabled ServiceS (bess) --------------------------- "Optimized Ingress Replication solution for EVPN", Jorge Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi, 2021-09-23, Network Virtualization Overlay (NVO) networks using EVPN as control plane may use Ingress Replication (IR) 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 NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO 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 IR in NVO networks. "Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Greg Hankins, Thomas King, 2021-10-06, This document describes the Ethernet Virtual Private Networks (EVPN) Proxy-ARP/ND function, augmented by the capability of the ARP/ND Extended Community. From that perspective this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy-ARP/ND function. The EVPN Proxy-ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points, Data Centers, and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains by reducing and even suppressing the flooding produced by address resolution in the EVPN network. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2021-10-07, This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. "IGMP and MLD Proxy for EVPN", Ali Sajassi, Samir Thoria, Mankamana Mishra, John Drake, Wen Lin, 2021-09-14, This document describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs. "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com, 2021-09-23, 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 DF 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 DF Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, 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 DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes a DF 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, 2021-05-24, 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 endusers 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 leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain. "EVPN VPWS Flexible Cross-Connect Service", Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Sami Boutros, Jorge Rabadan, 2021-06-07, 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 DF Election", Patrice Brissette, Ali Sajassi, LucAndre Burdet, John Drake, Jorge Rabadan, 2021-07-06, Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder election procedures for multi-homing 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 draft improves these procedures by providing a fast Designated Forwarder (DF) election upon recovery of the failed link or node associated with the multi-homing Ethernet Segment. The solution is independent of number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each PEs in the multi-homing 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, 2021-05-14, 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: o provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. o 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, 2021-04-19, 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 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, 2021-09-22, 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. "Extended Mobility Procedures for EVPN-IRB", Neeraj Malhotra, Ali Sajassi, Aparna Pattekar, Jorge Rabadan, Avinash Lingala, John Drake, 2021-10-02, 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, Samer Salam, Ali Sajassi, Sami Boutros, Greg Mirsky, 2021-06-14, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) 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, 2021-09-18, 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, 2021-04-26, 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-ISID 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 (ISID-based) CMAC-flush granularity is required. "SRv6 BGP based Overlay Services", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Robert Raszuk, Bruno Decraene, Shunwan Zhuang, Jorge Rabadan, 2021-04-11, This draft defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN". "Controller Based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk, Dante Pacella, Arkadiy Gulko, 2021-07-12, This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, mLDP FEC, or SR-P2MP Tree-ID) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. "EVPN multi-homing port-active load-balancing", Patrice Brissette, Ali Sajassi, LucAndre Burdet, Samir Thoria, Bin Wen, Eddie Leyton, Jorge Rabadan, 2021-07-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 a new port-active load-balancing mode. "Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin, Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2021-07-06, [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, 2021-10-18, 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, 2021-10-15, Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels. The EVPN multi-homing procedures may be different depending on the NVO 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 current 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 NVO tunnel depending on their own requirements. "Multicast and Ethernet VPN with Segment Routing P2MP", Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang, 2021-10-19, 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, LucAndre Burdet, John Drake, Jorge Rabadan, 2021-07-12, This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "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 [1]. "Multicast Source Redundancy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Wen Lin, Eric Rosen, 2021-08-04, 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: 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, LucAndre Burdet, Dan Voyer, 2021-05-03, 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 draft. "EVPN Interoperability Modes", Lukas Krattiger, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, 2021-05-31, Ethernet VPN (EVPN) provides different functional modes in the area of Service Interface, Integrated Route and Bridge (IRB) and IRB Core connectivity. This document specifies how the different EVPN functional modes and types can interoperate with each other. This document doesn't aim to redefine the existing functional modes but extend them for interoperability. "IPv6-Only PE Design for IPv4-NLRI with IPv6-NH", Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen, 2021-09-20, 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 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 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. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, 2021-08-01, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880. "Unsolicited BFD for Sessionless Applications", Enke Chen, Naiming Shen, Robert Raszuk, Reshad Rahman, 2021-10-21, For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). "Unaffiliated BFD Echo Function", Weiqiang Cheng, Ruixue Wang, Xiao Min, Reshad Rahman, Raj Boddireddy, 2021-06-22, 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 function where the local system supports BFD but the neighboring system does not support BFD. Bit Indexed Explicit Replication (bier) --------------------------------------- "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow, 2021-10-04, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola, 2021-10-04, This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. "BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, 2021-08-03, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless Eckert, Gregory Cauchie, Michael Menth, 2021-07-09, This memo describes per-packet stateless strict and loose path steered replication and forwarding for Bit Index Explicit Replication packets (RFC8279). It is called BIER Tree Engineering (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new semantic for bit positions (BP) that indicate adjacencies, as opposed to BIER in which BPs indicate Bit- Forwarding Egress Routers (BFER). BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible, for example by using separate BIER sub-domains (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay, and can therefore operate without depending on an Interior Gateway Routing protocol (IGP). As it operates on the same per-packet stateless forwarding principles, BIER-TE can also be a good fit to support multicast path steering in Segment Routing (SR) networks. "PIM Signaling Through BIER Core", Hooman Bidgoli, Fengman Xu, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang, 2021-07-25, Consider large networks deploying traditional PIM multicast service. Typically, each portion of these large networks have their own mandates and requirements. It might be desirable to deploy BIER technology in some part of these networks to replace traditional PIM services. In such cases downstream PIM states need to be signaled over the BIER Domain toward the source. This draft specifies the procedure to signal PIM join/prune messages through a BIER Domain, as such enabling the provisioning of traditional PIM services through a BIER Domain. These procedures are valid for forwarding PIM join/prune messages to the Source (SSM) or Rendezvous Point (ASM). "BIER Underlay Path Calculation Algorithm and Constraints", Zhaohui Zhang, Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands, Arkadiy Gulko, 2021-09-29, This document specifies general rules for the interaction between the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation. The semantics defined in this document update RFC8401, RFC8444, and draft-ietf-bier-ospfv3-extensions. "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", IJsbrand Wijnands, Mankamana Mishra, Xiaohu Xu, Hooman Bidgoli, 2021-05-30, 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 Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value. "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Dirk Trossen, Akbar Rahman, Chonggang Wang, Toerless Eckert, 2021-07-10, HTTP Level Multicast, using BIER, is described as a use case in the BIER Use Cases document. HTTP Level Multicast is used in today's video streaming and delivery services such as HTTP Live Streaming (HLS), Augmented Reality and Virtual Reality(AR/VR), generally realized over IP Multicast as well as other use cases such as software update delivery. A realization of "HTTP Multicast" over "IP Multicast" is described for the video delivery use case. IP Multicast is commonly used for IPTV services. Digital Video Broadcasting (DVB) and Broadband Forum (BBF) also develope a reference architecture for IP Multicast service. A few problems with IP Multicast, such as waste of transmission bandwidth, increase in signaling when there are few users are described. Realization over BIER, through a BIER Multicast Overlay Layer, is described as an alternative. How BIER Multicast Overlay operation improves over IP Multicast, such as reduction in signaling, dynamic creation of multicast groups to reduce signaling and bandwidth wastage is described. We conclude with a few next steps. "A YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE)", Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh Sivakumar, chenhuanan, 2021-05-17, This document defines a YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. "OSPFv3 Extensions for BIER", Peter Psenak, Nagendra Nainar, IJsbrand Wijnands, 2021-05-18, 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. Neither does BIER require an 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. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits set in BIER packet header. This document describes the OSPFv3 [RFC8362] protocol extensions required for BIER with MPLS encapsulation [RFC8296]. 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 (Bit Index Explicit Replication) Redundant Ingress Router Failover", Zheng Zhang, Greg Mirsky, Quan Xiong, Yisong Liu, Huanan Li, 2021-04-30, 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, 2021-06-14, BIER is a new architecture for the forwarding of multicast data packets without requiring per-flow state inside the network. This document describes how the existing BIER encapsulation specified in RFC 8296 works in an IPv6 non-MPLS network, 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. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore Tiruveedhula, 2021-06-18, This document defines methodologies for benchmarking EVPN and PBB- EVPN performance. EVPN is defined in RFC 7432, and is being deployed in Service Provider networks. Specifically, this document defines the methodologies for benchmarking EVPN/PBB-EVPN convergence, data plane performance, and control plane performance. "Benchmarking Methodology for Network Security Device Performance", Balamuhunthan Balarajah, Carsten Rossenhoevel, bmonkman, 2021-10-20, This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), next-generation intrusion prevention systems (NGIPS), and unified threat management (UTM) implementations. 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. The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFW and NGIPS. "Multiple Loss Ratio Search for Packet Throughput (MLRsearch)", Maciek Konstantynowicz, Vratko Polak, 2021-07-12, This document proposes changes to [RFC2544], specifically to packet throughput search methodology, by defining a new search algorithm referred to as Multiple Loss Ratio search (MLRsearch for short). Instead of relying on binary search with pre-set starting offered load, it proposes a novel approach discovering the starting point in the initial phase, and then searching for packet throughput based on defined packet loss ratio (PLR) input criteria and defined final trial duration time. One of the key design principles behind MLRsearch is minimizing the total test duration and searching for multiple packet throughput rates (each with a corresponding PLR) concurrently, instead of doing it sequentially. The main motivation behind MLRsearch is the new set of challenges and requirements posed by NFV (Network Function Virtualization), specifically software based implementations of NFV data planes. Using [RFC2544] in the experience of the authors yields often not repetitive and not replicable end results due to a large number of factors that are out of scope for this draft. MLRsearch aims to address this challenge in a simple way of getting the same result sooner, so more repetitions can be done to describe the replicability. Calendaring Extensions (calext) ------------------------------- "Support for iCalendar Relationships", Michael Douglass, 2021-10-13, This specification updates RELATED-TO defined in iCalendar (RFC5545) and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. "JSCalendar: Converting from and to iCalendar", Neil Jenkins, Robert Stepanek, Michael Douglass, 2021-07-08, This document provides the required methods for converting JSCalendar from and to iCalendar. "Calendar subscription upgrades", Michael Douglass, 2021-07-26, This specification updates [RFC5545] to add the value DELETED to the STATUS property. This specification also updates [RFC7240] to add the subscribe- enhanced-get and limit preferences. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Michael Douglass, 2021-07-26, This specification introduces a new iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. "Task Extensions to iCalendar", Adrian Apthorp, Michael Douglass, 2021-08-22, 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. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Additional Control Operators for CDDL", Carsten Bormann, 2021-09-27, The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat and .det for the construction of constants, .abnf/.abnfb for including ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for indicating the use of a non-basic feature in an instance. "Packed CBOR", Carsten Bormann, 2021-08-13, The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR 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 unpack the compressed form to make use of 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. "On storing CBOR encoded items on stable storage", Michael Richardson, Carsten Bormann, 2021-10-21, This document defines an on-disk format for CBOR objects that is friendly to common on-disk recognition systems such as the Unix file(1) command. "CBOR tags for IPv4 and IPv6 addresses and prefixes", Michael Richardson, Carsten Bormann, 2021-10-20, This specification defines two CBOR Tags for use with IPv6 and IPv4 addresses and prefixes. // RFC-EDITOR-please-remove: This work is tracked at // https://github.com/cbor-wg/cbor-network-address "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", Carsten Bormann, Ben Gamari, Henk Birkholz, 2021-05-19, 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. 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, 2021-07-12, 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, 2021-07-12, 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. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "A YANG Data Model for Flexi-Grid Optical Networks", Universidad de Madrid, Daniel Burrero, Daniel King, Young Lee, Haomian Zheng, 2021-07-12, 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). "Transport Northbound Interface Applicability Statement", Italo Busi, Daniel King, Haomian Zheng, Yunbin Xu, 2021-09-29, This document provides an analysis of the applicability of the YANG models defined by the IETF (Traffic Engineering Architecture and Signaling (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in particular) to support ODU transit services, Transparent client services and EPL/EVPL Ethernet services over OTN single and multi-domain network scenarios. This document also describes how existing YANG models can be used through a number of 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, 2021-09-08, This document provides a YANG data model for Layer 1 Connectivity Service Model (L1CSM). The intent of this document is to provide a Layer 1 service model exploiting YANG data model, which can be utilized by a customer network controller to initiate a service request connectivity as well as retrieving service states toward a Layer 1 network controller communicating with its customer network controller. This YANG model is NMDA-compliant. "A YANG Data Model for Flexi-Grid Media Channels", Universidad de Madrid, Daniel Burrero, Daniel King, Victor Lopez, Italo Busi, Oscar de Dios, Young Lee, Gabriele Galimberti, 2021-07-12, This document defines a YANG model for managing flexi-grid optical 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). "Applicability of GMPLS for B100G Optical Transport Network", Qilei Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti, 2021-06-14, This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up ODUk (e.g., ODUflex) LSP over 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, 2021-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, Andreas Burk, Dharini Hiremagalur, Gert Grammel, 2021-07-12, This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 [ITU.G698.2] or any other ITU-T recommendation. More context about the state of the Coherent transceivers is described in draft-many- coherent-DWDM-if-control. 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 means 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", Young Lee, Esther Le Rouzic, Victor Lopez, Gabriele Galimberti, Dieter Beller, 2021-07-08, 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, Yunbin Xu, Yang Zhao, Xufeng Liu, Giuseppe Fioccola, 2021-07-09, 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, 2021-09-07, 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, 2021-09-07, 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 Layer 0 Types - Revision 2", Dieter Beller, Sergio Belotti, Haomian Zheng, Italo Busi, Esther Le Rouzic, 2021-08-10, This document defines a collection of common data types and groupings in the YANG data modeling language, which are used in several YANG modules for wavelength Division multiplexing (WDM) transport networks. The YANG module ietf-layer0-types-ext updates ietf- layer0-types defined in draft-ietf-ccamp-layer0-types, which has been reduced in scope prior to publication to only cover spectrum management related aspects required for the YANG module ietf-wson- topology defined in draft-ietf-ccamp-wson-yang. To be completed Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for Content Delivery Network Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, Phil Sorber, 2021-02-11, This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile. The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single Content Delivery Network (CDN) scenarios. "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile, Sanjay Mishra, 2021-09-10, The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). "CDNI Control Triggers Interface Extensions", Ori Finkelman, Sanjay Mishra, Nir Sopher, 2021-06-20, Open Caching architecture is a use case of Content Delivery Network 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 defines extensions to the Content Delivery Network Interconnection (CDNI) Control Interface/Triggers defined in RFC 8007. These extensions are derived from requirements raised by Open Caching architecture but are also applicable to CDNI use cases in general. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice, Jerome Martinez, 2021-05-25, 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, 2021-10-09, 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, 2021-10-09, 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, 2021-10-09, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. "Free Lossless Audio Codec", Michael Richardson, Andrew Weaver, 2021-04-27, This document defines FLAC, which stands for Free Lossless Audio Codec, a free, open source codec for lossless audio compression and decompression. "Matroska Media Container Control Track Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2021-10-09, This document defines the Control Track usage found in the Matroska container. "Matroska Media Container Chapter Codecs Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2021-10-09, This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu. Crypto Forum (cfrg) ------------------- "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2021-09-26, 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. 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, 2021-05-17, A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies several VRF constructions that are secure in the cryptographic random oracle model. One VRF uses RSA and the other VRF uses Elliptic Curves (EC). "Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick Sullivan, Riad Wahby, Christopher Wood, 2021-09-16, This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. "Hybrid Public Key Encryption", Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, Christopher Wood, 2021-09-02, This document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one which authenticates possession of a pre-shared key, and two optional ones which authenticate possession of a KEM private 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. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman key agreement, HKDF, and SHA2. 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, 2021-07-06, An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for computing the output of a PRF. One party (the server) holds the PRF secret key, and the other (the client) holds the PRF input. The 'obliviousness' property ensures that the server does not learn anything about the client's input during the evaluation. The client should also not learn anything about the server's secret PRF key. Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF). In this setting, the client can verify that the server's output is indeed the result of evaluating the underlying PRF with just a public key. This document specifies OPRF and VOPRF constructions instantiated within prime-order groups, including elliptic curves. "KangarooTwelve", =?utf-8?q?Beno=C3=AEt_Viguier?=, David Wong, Giles Van Assche, Quynh Dang, Joan Daemen, 2021-08-22, 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. "Pairing-Friendly Curves", Yumi Sakemi, Tetsutaro Kobayashi, Tsunekazu Saito, Riad Wahby, 2021-07-30, 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, 2021-07-25, This document describes CPace which is a protocol for two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. This method was tailored for constrained devices, is compatible with any group of both prime- and non-prime order, and comes with a security proof providing composability guarantees. "Usage Limits on AEAD Algorithms", Felix Guenther, Martin Thomson, Christopher Wood, 2021-07-12, 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", Hugo Krawczyk, Daniel Bourdrez, Kevin Lewi, Christopher Wood, 2021-07-12, 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, George Tankersley, Filippo Valsorda, Isis Lovecruft, Mike Hamburg, 2021-08-04, 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 Signatures with FROST", Chelsea Komlo, Ian Goldberg, T Wilson-Brown, 2021-08-11, In this draft, we present a 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 EdDSA verification of signatures. However, this draft does not generate deterministic nonces as defined by EdDSA, to ensure protection against a key-recovery attack that is possible when even only one participant is malicious. "RSA Blind Signatures", Frank Denis, Frederic Jacobs, Christopher Wood, 2021-08-02, This document specifies the RSA-based blind signature scheme with appendix (RSA-BSSA). 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. Constrained RESTful Environments (core) --------------------------------------- "CoRE Resource Directory", Christian Amsuess, Zach Shelby, Michael Koster, Carsten Bormann, Peter van der Stok, 2021-03-07, In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. "CBOR Encoding of Data Modeled with YANG", Michel Veillette, Ivaylo Petrov, Alexander Pelov, Carsten Bormann, 2021-06-24, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and the yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). "Dynamic Resource Linking for Constrained RESTful Environments", Michael Koster, Bill Silverajan, 2021-07-12, This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink "YANG Schema Item iDentifier (YANG SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, Carsten Bormann, 2021-06-24, YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of YANG SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. "CoAP: Echo, Request-Tag, and Token Processing", Christian Amsuess, John Mattsson, Goeran Selander, 2021-10-04, This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. "Group OSCORE - Secure Group Communication for CoAP", Marco Tiloca, Goeran Selander, Francesca Palombini, John Mattsson, Jiye Park, 2021-07-12, 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. "SenML Data Value Content-Format Indication", Ari Keranen, Carsten Bormann, 2021-10-21, The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for indicating the content format of those binary data values, i.e., their Internet media type including parameters as well as any content codings applied. "Constrained Resource Identifiers", Carsten Bormann, Henk Birkholz, 2021-07-25, 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. "Group Communication for the Constrained Application Protocol (CoAP)", Esko Dijk, Chonggang Wang, Marco Tiloca, 2021-07-12, 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 RFC7390, while it updates RFC7252 and RFC7641. "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission", Mohamed Boucadair, Jon Shallow, 2021-05-26, This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to, but distinct from, the CoAP Block1 and Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options are not intended to replace Block1 and Block2 Options, but rather have the goal of supporting Non-confirmable messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 Options support faster recovery should any of the blocks get lost in transmission. "Combining EDHOC and OSCORE", Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander, 2021-07-12, This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP 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, 2021-07-12, 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, Bill Silverajan, 2021-07-12, 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 TBD CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE): Structures and Process", Jim Schaad, 2021-02-01, Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. "CBOR Object Signing and Encryption (COSE): Initial Algorithms", Jim Schaad, 2020-09-24, Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Jim Schaad, 2020-12-14, 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): Hash Algorithms", Jim Schaad, 2020-09-14, The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. "CBOR Object Signing and Encryption (COSE): Countersignatures", Jim Schaad, Russ Housley, 2021-06-23, 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. "CBOR Encoded X.509 Certificates (C509 Certificates)", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2021-07-12, 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. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", Mark Baushke, 2021-08-06, This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This document updates RFC 4250, RFC 4253, RFC 4432, and RFC 4462. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking (DetNet) YANG Model", Xuesong Geng, Yeoncheol Ryoo, Don Fedyk, Reshad Rahman, Zhenqiang Li, 2021-10-04, This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data for 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. An operator or network controller programs the configuration of the devices. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). "DetNet Bounded Latency", Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas, 2021-09-01, This document references specific queuing mechanisms, defined in other documents, that can be used to control packet transmission at each output port and achieve the DetNet qualities of service. This document presents a timing model for sources, destinations, and the DetNet transit nodes that relay packets that is applicable to all of those referenced queuing mechanisms. Using the model presented in this document, it should be possible for an implementor, user, or standards development organization to select a particular set of queuing mechanisms for each device in a DetNet network, and to select a resource reservation algorithm for that network, so that those elements can work together to provide the DetNet service. "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane", Greg Mirsky, Mach Chen, 2021-10-18, This document defines format and use principals 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, 2021-09-19, This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. "Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)", Greg Mirsky, Fabrice Theoleyre, Georgios Papadopoulos, Carlos Bernardos, Balazs Varga, Janos Farkas, 2021-10-14, 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. Dynamic Host Configuration (dhc) -------------------------------- "YANG Data Model for DHCPv6 Configuration", Ian Farrer, 2021-07-02, This document describes YANG data modules for the configuration and management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6) servers, relays, and clients. "DHCPv6 Extension Practices and Considerations", Ren Gang, Lin He, Ying Liu, 2021-05-18, IP addresses assume an increasing number of attributes as communication identifiers to meet different requirements. Privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol as required. This document provides current extension practices and typical DHCPv6 server software in terms of extensions, defines a general model of DHCPv6, discusses some extension points, and presents extension cases. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2020-03-09, In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes 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. Dispatch (dispatch) ------------------- "ECMAScript Media Types Updates", Matthew Miller, Myles Borins, Mathias Bynens, Bradley Farias, 2021-10-12, This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with implementation experiences. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Todd Herr, John Levine, 2021-08-18, 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 severity of concern regarding failed verification, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFC 7489. "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting", Steven Jones, Alessandro Vesely, 2021-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, 2021-08-18, 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, 2021-10-12, 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. "Transport Network aware Mobility for 5G", Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley, 2021-09-22, This document specifies a framework and mapping of slices in 5G mobile systems to transport network slices in IP, Layer 2 or Layer 1 transport networks. Slices in 5G systems are characterized by latency bounds, reservation guarantees, jitter, data rates, availability, mobility speed, usage density, criticality and priority. These characteristics mapped to transport network slice include bandwidth, latency and criteria such as isolation, directionality and disjoint routes. Mobile slice criteria are mapped to the appropriate transport slice and capabilities offered in backhaul, midhaul and fronthaul connectivity segments between radio side network functions and user plane function(gateway). This document describes how mobile network functions map its slice criteria to identifiers in IP and Layer 2 packets that transport network segments use to grant transport layer services during UE mobility scenarios. 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, Andrew Sullivan, 2021-06-21, This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] "DNS Transport over TCP - Operational Requirements", John Kristoff, Duane Wessels, 2021-10-13, This document updates RFC 1123 and RFC 1536. This document strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. Such encouragement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. "DNS Query Name Minimisation to Improve Privacy", Stephane Bortzmeyer, Ralph Dolmans, Paul Hoffman, 2021-09-01, This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. "DNS Catalog Zones", Peter van Dijk, Libor Peltan, Ondrej Sury, Willem Toorop, Leo Vandewoestijne, 2021-08-25, 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. "Glue In DNS Referral Responses Is Not Optional", Mark Andrews, Shumon Huque, Paul Wouters, Duane Wessels, 2021-10-11, The DNS uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone. Authoritative Servers are expected to return all available glue records in referrals. If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP 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, 2021-10-12, 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, 2021-06-23, EDNS0 enables a DNS server to send large responses using UDP and is widely deployed. Path MTU discovery remains widely undeployed due to security issues, and IP fragmentation has exposed weaknesses in application protocols. Currently, DNS is known to be the largest user of IP fragmentation. 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, 2021-09-28, 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). "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Ralph Dolmans, 2021-07-12, 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, 2021-09-28, 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. "Revised IANA Considerations for DNSSEC", Paul Hoffman, 2021-10-07, This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS (Delegation Signer) records and NSEC3 (Hashed Authenticated Denial of Existence) parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. "DNS Error Reporting", Roy Arends, Matt Larson, 2021-04-27, 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. "Guidance for NSEC3 parameter settings", Wes Hardaker, Viktor Dukhovni, 2021-10-15, NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising there are no names that exist between two domainnames within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domainname pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. "The "RRSERIAL" EDNS option for the SOA serial of a RR's zone", Hugo Salgado, Mauricio Ereche, 2021-06-11, The "RRSERIAL" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered Resource Record. This "RRSERIAL" 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. Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "An EDNS0 option to negotiate Leases on DNS Updates", Stuart Cheshire, Ted Lemon, 2021-07-27, This document proposes a new EDNS0 option that can be used by DNS Update clients 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 "Service Registration Protocol for DNS-Based Service Discovery", Ted Lemon, Stuart Cheshire, 2021-07-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. "Advertising Proxy for DNS-SD Service Registration Protocol", Stuart Cheshire, Ted Lemon, 2021-07-12, An Advertising Proxy allows a device that accepts service registrations using Service Registration Protocol (SRP) to make those registrations visible to legacy clients that only implement Multicast DNS. DDoS Open Threat Signaling (dots) --------------------------------- "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Mohamed Boucadair, Tirumaleswar Reddy.K, Wei Pan, 2021-07-06, This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide some guidance for DOTS clients/gateways when multihomed. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home", Tirumaleswar Reddy.K, Mohamed Boucadair, Jon Shallow, 2021-05-27, This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD/TBA statements with the assignments made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", Mohamed Boucadair, Tirumaleswar Reddy.K, Ehud Doron, chenmeiling, Jon Shallow, 2021-05-25, This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. "Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", Yuhei Hayashi, chenmeiling, Li Su, 2021-07-06, Denial-of-service 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: 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, 2021-08-23, This document specifies new DOTS signal channel configuration parameters that are negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 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. DNS PRIVate Exchange (dprive) ----------------------------- "DNS over Dedicated QUIC Connections", Christian Huitema, Sara Dickinson, Allison Mankin, 2021-10-20, This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP. "Recursive to Authoritative DNS with Unauthenticated Encryption", Paul Hoffman, Peter van Dijk, 2021-09-28, This document describes a use case and a method for a DNS recursive resolver to use unauthenticated encryption when communicating with authoritative servers. The motivating use case for this method is that more encryption on the Internet is better, and some resolver operators believe that unauthenticated encryption is better than no encryption at all. The method described here is optional for both the recursive resolver and the authoritative server. Drone Remote ID Protocol (drip) ------------------------------- "Drone Remote Identification Protocol (DRIP) Requirements", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Andrei Gurtov, 2021-09-08, This document defines terminology and requirements for Drone Remote Identification Protocol (DRIP) Working Group solutions to support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and will enable online and offline verification that RID information is trustworthy. "Drone Remote Identification Protocol (DRIP) Architecture", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Shuai Zhao, Andrei Gurtov, 2021-07-25, This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document. "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification (UAS RID)", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2021-10-20, 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). Within the context of RID, HHITs will be called DRIP Entity Tags (DET). HHITs self-attest to the included explicit hierarchy that provides Registrar discovery for 3rd-party identifier attestation. "DRIP Authentication Formats for Broadcast RID", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2021-10-21, This document describes how to include trust into the ASTM Remote ID specification defined in ASTM F3411-19 under a Broadcast Remote ID (RID) scenario. It defines a few different message schemes (based on the Authentication Message) that can be used to assure past messages sent by a UA and also act as an assurance for UA trustworthiness in the absence of Internet connectivity at the receiving node. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane, 2021-01-25, This Internet Draft presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. "Bundle Protocol Security Specification", Edward Birrane, Kenneth McKeever, 2021-02-16, This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol. "Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4", Brian Sipos, Michael Demmer, Joerg Ott, Simon Perreault, 2021-10-06, This document describes a TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a reliable transport of such bundles. This version of TCPCL also includes security and extensibility mechanisms. "BPSec Default Security Contexts", Edward Birrane, Alex White, Sarah Heiner, 2021-07-25, This document defines default integrity and confidentiality security contexts that can be used with the Bundle Protocol Security Protocol (BPSec) implementations. These security contexts are intended to be used for both testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "A LoST extension to return complete and similar location info", Brian Rosen, Roger Marshall, Jeff Martin, 2021-10-11, This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the message. This document defines a new extension to the message within the LoST protocol [RFC5222] that enables the LoST protocol to return in a response a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for an invalid location. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as a compilation of CAtype xml elements within the existing LoST message structure. "Validation of Locations Around a Planned Change", Brian Rosen, 2021-10-11, This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows planned changes to the data to be handled smoothly. 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. Revision of core Email specifications (emailcore) ------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 2021-10-02, This document is a specification of the basic protocol for Internet electronic mail transport. It 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. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces the earlier version with the same title in RFC 5321. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 (Message Submission) as an Internet Standard.]] "Applicability Statement for IETF Core Email Protocols", John Klensin, Kenneth Murchison, Ekow Sam, 2021-08-06, 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, 2021-09-29, 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) ----------------------- "Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)", John Mattsson, Mohit Sethi, 2021-10-20, 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-Transport Layer Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking, when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", Jari Arkko, Vesa Lehtovirta, Vesa Torvinen, Pasi Eronen, 2021-05-10, The 3GPP Mobile Network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This document is the most recent specification of EAP-AKA', including, for instance, details and references about related to operating EAP-AKA' in 5G networks. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC- SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. This version of EAP-AKA' specification specifies the protocol behaviour for both 4G and 5G deployments, whereas the previous version only did this for 4G. "Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods", Mohit Sethi, John Mattsson, Sean Turner, 2020-11-20, The Extensible Authentication Protocol (EAP), defined in RFC3748, provides a standard mechanism for support of multiple authentication methods. EAP-Transport Layer Security (EAP-TLS) and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round-trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available. "Nimble out-of-band authentication for EAP (EAP-NOOB)", Tuomas Aura, Mohit Sethi, Aleksi Peltonen, 2021-09-03, The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication, and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a non-network input or output interface, such as a display, microphone, speaker, or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. "TLS-based EAP types and TLS 1.3", Alan DeKok, 2021-06-22, EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], 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. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "IMAP QUOTA Extension", Alexey Melnikov, 2021-10-21, This document defines a QUOTA extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This document obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. "Sieve Email Filtering: Snooze Extension", Kenneth Murchison, Ricardo Signes, Neil Jenkins, 2021-08-16, 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, 2021-08-19, This document creates a registry of Sieve (RFC 5228) actions in order to help developers and Sieve extension writers track interactions between different extensions. Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- "Grant Negotiation and Authorization Protocol", Justin Richer, Aaron Parecki, Fabien Imbault, 2021-09-24, GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. "Grant Negotiation and Authorization Protocol Resource Server Connections", Justin Richer, Aaron Parecki, Fabien Imbault, 2021-07-12, 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) -------------------------------- "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2021-08-31, The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Alexander Azimov, 2021-04-28, 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 ietf-idr-bgp-open-policy draft. "TLV support for BMP Route Monitoring and Peer Down Messages", Paolo Lucente, Yunan Gu, 2021-07-27, Most of the message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data. However, Route Monitoring messages (to provide a snapshot of the monitored Routing Information Base) and Peer Down messages (to indicate that a peering session was terminated) do not. Supporting optional data in TLV format across all BMP message types allows for an 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 optional TLV data in all message types. "AS Path Prepending", Mike McBride, Doug Madory, Jeff Tantsura, Robert Raszuk, Hongwei Li, Jakob Heitz, Gyan Mishra, 2021-07-08, AS Path Prepending provides a tool to manipulate the BGP AS_Path attribute through prepending multiple entries of an AS. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the internet. This document provides guidance with the use of AS Path Prepending, including alternative solutions, in order to avoid negatively affecting the internet. Home Networking (homenet) ------------------------- "Simple Provisioning of Public Names for Residential Networks", Daniel Migault, Ralf Weber, Michael Richardson, Ray Hunter, 2021-05-13, Home owners often have IPv6 devices that they wish to access over the Internet using names. Outsourcing the DNS servers to a DNS infrastructure protects against possible DDoS attacks as well as sudden renumbering of the home network. It has been possible to register and populate a DNS Zone with names since DNS became a thing, but it has been an activity typically reserved for experts. This document automates the process through creation of a Homenet Naming Authority (HNA), whose responsibility is to select, sign and publish names to a set of publicly visible servers. This document describes the mechanism that enables the HNA to outsource the naming service to the DNS Outsourcing Infrastructure (DOI) via a Distribution Manager (DM). In addition, this document deals with publication of a corresponding reverse zone. "DHCPv6 Options for Home Network Naming Authority", Daniel Migault, Ralf Weber, Tomek Mrugalski, 2021-05-13, This document defines DHCPv6 options so an agnostic 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, 2021-09-15, 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 Group. It has been reviewed, tried, and tested by both by the research group as well as by researchers and practitioners from outside the research group. The research group acknowledges that the understanding of the impact of internet protocols and architecture on society is a developing practice and is a body of research that is still in development. Building Blocks for HTTP APIs (httpapi) --------------------------------------- "RateLimit Header Fields for HTTP", Roberto Polli, Alex Ruiz, 2021-05-11, This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields for HTTP, thus allowing servers to publish current service limits and clients to shape their request policy and avoid being throttled out. "The Deprecation HTTP Header Field", Sanjay Dalal, Erik Wilde, 2021-07-10, The HTTP Deprecation Response Header Field can be used to signal to consumers of a URI-identified resource that the resource has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional context for the deprecation, and possibly ways in which clients can find a replacement for the deprecated resource. "Linkset: Media Types and a Link Relation Type for Link Sets", Erik Wilde, Herbert Van de Sompel, 2021-10-21, This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. Note to Readers Please discuss this draft on the "Building Blocks for HTTP APIs" mailing list (https://www.ietf.org/mailman/listinfo/httpapi). Online access to all versions and files is available on GitHub (https://github.com/ietf-wg-httpapi/linkset). "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal, 2021-10-13, This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. 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, 2021-07-01, 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. HTTP (httpbis) -------------- "Cookies: HTTP State Management Mechanism", Lily Chen, Steven Englehardt, Mike West, John Wilander, 2021-10-19, 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. "Expect-CT Extension for HTTP", estark@google.com, 2018-12-09, This document defines a new HTTP header field named Expect-CT, which allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency deployments. Further, web host operaters can use Expect-CT to ensure that, if a UA which supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. "Building Protocols with HTTP", Mark Nottingham, 2021-08-27, Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet, but might be applicable in other situations. This document obsoletes [RFC3205]. "HTTP Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 2021-09-12, The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. "HTTP/1.1", Roy Fielding, Mark Nottingham, Julian Reschke, 2021-09-12, The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. "HTTP Semantics", Roy Fielding, Mark Nottingham, Julian Reschke, 2021-09-12, The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. "The Cache-Status HTTP Response Header Field", Mark Nottingham, 2021-08-17, To aid debugging, HTTP caches often append header fields to a response explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model. "The Proxy-Status HTTP Response Header Field", Mark Nottingham, Piotr Sikora, 2021-10-13, This document defines the Proxy-Status HTTP field to convey the details of intermediary response handling, including generated errors. "Digest Fields", Roberto Polli, Lucas Pardue, 2021-09-27, This document defines HTTP fields that support integrity checksums. The Digest field can be used for the integrity of HTTP representations. The Content-Digest field can be used for the integrity of HTTP message content. Want-Digest and Want-Content- Digest can be used to indicate a sender's desire to receive integrity fields respectively. This document obsoletes RFC 3230. "Extensible Prioritization Scheme for HTTP", Kazuho Oku, Lucas Pardue, 2021-09-30, This document describes a scheme for prioritizing HTTP responses. This scheme expresses the priority of each HTTP response using absolute values, rather than as a relative relationship between a group of HTTP responses. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing the responses. These share a common format structure that is designed to provide future extensibility. "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny, 2021-08-13, 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. "Hypertext Transfer Protocol Version 2 (HTTP/2)", Martin Thomson, Cory Benfield, 2021-09-26, This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFC 7540 and RFC 8740. "HTTP SEARCH Method", Julian Reschke, Ashok Malhotra, James Snell, 2021-06-08, This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. "Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications", Brian Campbell, Mike Bishop, 2021-06-08, This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. "Targeted HTTP Cache Control", Stephen Ludin, Mark Nottingham, Yuchen Wu, 2021-10-14, This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, targeted at Content Delivery Network (CDN) caches. "HTTP Alternative Services", Mike Bishop, Martin Thomson, 2021-08-31, This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. "Bootstrapping WebSockets with HTTP/3", Ryan Hamilton, 2021-09-09, The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered. This document describes the mechanism for HTTP/3. 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, 2021-09-15, This document describes an information model and a YANG data model for the Consumer-Facing Interface between an Interface to Network Security Functions (I2NSF) User and Security Controller in an 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 interface. The information model is based on the "Event-Condition-Action" (ECA) policy model defined by a capability information model for I2NSF, and the data model is defined for enabling different users of a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. "I2NSF Network Security Function-Facing Interface YANG Data Model", Jinyong Kim, Jaehoon Jeong, J., PARK, Susan Hares, Qiushi Lin, 2021-10-04, 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 corresponds to the information model for NSF-Facing Interface in the I2NSF framework. "I2NSF Capability YANG Data Model", Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, Qiushi Lin, 2021-10-04, 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", Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J., PARK, 2021-10-04, This document defines an information model and a YANG data model for 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, 2021-10-15, 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 comprehensive 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 data diagram, but also the corresponding YANG data model. Internet Architecture Board (iab) --------------------------------- "The Harmful Consequences of the Robustness Principle", Martin Thomson, 2021-07-12, 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. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time. For a protocol that is actively maintained, the robustness principle can, and should, be avoided. "Long-term Viability of Protocol Extension Mechanisms", Martin Thomson, Tommy Pauly, 2021-10-12, The ability to change protocols depends on exercising the extension and version negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. "Nameservers for the Address and Routing Parameter Area ("arpa") Domain", Kim Davies, Jari Arkko, 2021-07-12, This document describes revisions to operational practices to separate function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone. "RFC Editor Model (Version 3)", Peter Saint-Andre, 2021-10-21, This document describes updated processes for defining and implementing policies regarding the RFC Series as a whole and thus specifies version 3 of RFC Editor Model. The model defines two high- level tasks related to the RFC Series. Policy definition is the responsibility of the RFC Series Working Group (RSWG), which produces policy proposals that are subject to approval by the RFC Series Approval Board (RSAB). Policy implementation is primarily the responsibility of the RFC Production Center (RPC), under the ultimate authority of the IETF Administration Limited Liability Company (IETF LLC). This document obsoletes RFC 8728. This document updates RFC 7841, RFC 8729, and RFC 8730. Information-Centric Networking (icnrg) -------------------------------------- "Experimental Scenarios of ICN Integration in 4G Mobile Networks", Prakash suthar, Milan Stolic, Anil Jangam, Dirk Trossen, 2021-07-30, 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this draft is to list the options for use of Information centric technology (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide for using ICN either natively or with existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as, network- layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks. "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Hitoshi Asaeda, Atsushi Ooka, Xun Shao, 2021-07-27, 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. "Design Considerations for Name Resolution Service in ICN", Jungha Hong, Taewan You, Lijun Dong, Cedric Westphal, Borje Ohlman, 2021-07-28, This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in ICN. An NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. for forwarding the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG). "Architectural Considerations of ICN using Name Resolution Service", Jungha Hong, Taewan You, Ved Kafle, 2021-02-12, This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information- Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information- Centric Networking Research Group (ICNRG). "ICN Adaptation to LoWPAN Networks (ICN LoWPAN)", Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin, 2021-09-27, This document defines a convergence layer for CCNx and NDN over IEEE 802.15.4 LoWPAN networks. A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by 6LoWPAN is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide state local to the LoWPAN and replace names in data packets by short local identifiers. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). Inter-Domain Routing (idr) -------------------------- "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 2021-10-21, This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, 2021-05-05, This document describes a mechanism to collect the Traffic Engineering and 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, 2021-05-12, 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 an extended community also are defined. "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas, 2021-07-11, 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, 2021-08-15, 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. "Route Leak Prevention and Detection using Roles in UPDATE and OPEN Messages", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Kotikalapudi Sriram, 2021-10-13, Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the eBGP neighbor, or enforcement that the two eBGP speakers agree on the relationship. This document enhances the BGP OPEN message to establish an agreement of the relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Eric Rosen, Dhanendra Jain, Steven Lin, 2021-06-07, This document defines a new BGP SAFI with a new NLRI to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned 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. New sub-TLVs for the Tunnel Encapsulation Attribute are defined for signaling information about these candidate paths. "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, 2021-08-17, 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 Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, 2021-10-12, This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. "BGP Flow Specification for SRv6", Zhenbin Li, Lei Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Xufeng Liu, 2021-08-25, This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. "BGP Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, Daniel Bernier, Bruno Decraene, 2021-06-08, 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. "Application-Specific Attributes Advertisement with BGP Link-State", Ketan Talaulikar, Peter Psenak, Jeff Tantsura, 2021-06-25, Various link attributes have been defined in link-state routing protocols like OSPF and IS-IS in the context of the MPLS Traffic Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have been defined to distribute these attributes along with other topology information from these link-state routing protocols. Many of these link attributes can be used for applications other than MPLS-TE or GMPLS. Extensions to link-state routing protocols have been defined for such link attributes that enable distribution of their application- specific values. This document defines extensions to BGP-LS address- family to enable advertisement of these application-specific attributes as a part of the topology information from the network. "Flexible Algorithm Definition Advertisement with BGP Link-State", Ketan Talaulikar, Peter Psenak, Shawn Zandi, Gaurav Dawra, 2021-06-07, Flexible Algorithm is a solution that allows routing protocols (viz. 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 distribute manner using a Flex Algorithm definition. This definition provisioned on one or more routers and propagated (viz. OSPF and IS- IS flooding) through the network. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This draft defines extensions to BGP- LS address-family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. "BGP Link-State Extensions for Seamless BFD", Zhenbin Li, Shunwan Zhuang, Ketan Talaulikar, Sam Aldrin, Jeff Tantsura, Greg Mirsky, 2021-03-08, Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the Seamless BFD (S-BFD) Discriminators. This draft defines extensions to the BGP Link-state address-family to carry the S-BFD Discriminators information via BGP. "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari, Kotikalapudi Sriram, Lilia Hannachi, Jeffrey Haas, 2021-09-12, 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 and AS_CONFED_SET types 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 by eliminating AS_SET and AS_CONFED_SET types, and obsoletes RFC 6472. "Distribution of Link-State and Traffic Engineering Information Using BGP", Ketan Talaulikar, 2021-07-26, In a number of 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 is applicable to physical and virtual 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 RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates which it made to RFC 7752. "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu, 2021-04-25, 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, 2021-07-08, 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, 2021-08-03, 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, 2021-07-08, 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, 2021-10-20, Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate 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 Extended Community Registries Update", Christoph Loibl, 2021-10-13, This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and thus misleading. This document updates RFC7153. "Signaling Maximum Transmission Unit (MTU) using BGP-LS", Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair, 2021-05-25, BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path mtu of SR tunnel. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. "BGP SR Policy Extensions to Enable IFIT", Fengwei Qin, Hang Yuan, Tianran Zhou, Giuseppe Fioccola, Yali Wang, 2021-07-09, 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. "Requirements and Considerations in BGP Peer Auto-Configuration", Randy Bush, Jie Dong, Jeffrey Haas, Warren Kumari, 2021-06-25, This draft is an exploration of the requirements, the alternatives, and trade-offs in BGP peer auto-discovery at various layers in the stack. It is based on discussions in the IDR Working Group BGP Autoconf Design Team. The current target environment is the datacenter. This document is not intended to become an RFC. "BGP Link-State Extensions for BGP-only Fabric", Ketan Talaulikar, Clarence Filsfils, krishnaswamy ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani, 2021-09-13, BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed view of the nodes and underlying links in the topology along with their attributes similar to one available when using link state routing protocols. Such a view of a BGP-only fabric enables use cases like traffic engineering and forwarding of services along paths other than the BGP best path selection. This document defines extensions to the BGP Link-state address-family (BGP-LS) and the procedures for advertisement of the topology in a BGP-only network. It also describes a specific use-case for traffic engineering based on Segment Routing. "BGP UPDATE for SDWAN Edge Discovery", Linda Dunbar, Susan Hares, Robert Raszuk, Kausik Majumdar, Gyan Mishra, 2021-09-03, The document describes the encoding of BGP UPDATE messages for the SDWAN edge node 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, 2021-10-08, This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. IP Performance Measurement (ippm) --------------------------------- "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip Eardley, Alfred Morton, Aamer Akhter, 2020-03-09, This document defines the format for the IANA Performance Metrics Registry. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. "Initial Performance Metrics Registry Entries", Alfred Morton, Marcelo Bagnulo, Philip Eardley, Kevin D'Souza, 2020-03-09, This memo defines the set of Initial Entries for the IANA Performance Metrics Registry. The set includes: UDP Round-trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP Round-trip Latency and Loss, and TCP round-trip Latency and Loss. "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Alfred Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, 2018-07-02, This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). The document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using a NDMA- compliant YANG model. "Data Fields for In-situ OAM", Frank Brockners, Shwetha Bhandari, Tal Mizrahi, 2021-10-03, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. This document discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be encapsulated into a variety of protocols such as NSH, Segment Routing, Geneve, or IPv6. In-situ OAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Greg Mirsky, Xiao Min, Wei Luo, 2021-07-12, 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. "Advanced Unidirectional Route Assessment (AURA)", Jose Alvarez-Hamelin, Alfred Morton, Joachim Fabini, Carlos Pignataro, Ruediger Geib, 2020-08-13, This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology, based on the IP Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multi- path technologies. "In-situ OAM IPv6 Options", Shwetha Bhandari, Frank Brockners, 2021-07-31, 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. "In-situ OAM Loopback and Active Flags", Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel, Jennifer Lemon, 2021-10-13, In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags. "Metrics and Methods for One-way IP Capacity", Alfred Morton, Ruediger Geib, Len Ciavattone, 2021-06-09, This memo revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-Layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. "In-situ OAM Direct Exporting", Haoyu Song, Barak Gafni, Tianran Zhou, Zhenbin Li, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Tal Mizrahi, 2021-10-13, In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type called the Direct Export (DEX) option, which is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2021-07-12, 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, 2021-07-11, 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, 2021-09-09, 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, 2021-07-25, This document describes an extension to the echo request/reply mechanisms used in IPv6, MPLS, SFC and BIER environments, which can be used within an IOAM domain, allowing the IOAM encapsulating node to acquire the enabled IOAM capabilities of each IOAM transit node and/or IOAM decapsulating node. "Integrity of In-situ OAM Data Fields", Frank Brockners, Shwetha Bhandari, Tal Mizrahi, 2021-10-19, 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. 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, 2021-10-19, 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 provides best current practices. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana Prasad, 2021-05-04, 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. "Intermediate Exchange in the IKEv2 Protocol", Valery Smyslov, 2021-08-03, This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. "IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security", Christian Hopps, 2021-09-03, This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. 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, 2021-07-11, 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. "Multiple Key Exchanges in IKEv2", C. Tjhai, M. Tomlinson, G. Bartlett, Scott Fluhrer, Daniel Van Geest, Oscar Garcia-Morchon, Valery Smyslov, 2021-09-30, 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 key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application 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 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. "IP Traffic Flow Security YANG Module", Don Fedyk, Christian Hopps, 2021-10-04, 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, 2021-06-27, Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has 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 adds a Status column to the IANA IKEv2 Transform Type registries. "TCP Encapsulation of IKE and IPsec Packets", Valery Smyslov, Tommy Pauly, 2021-04-29, This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates specification for TCP encapsulation by including additional calarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. "Definitions of Managed Objects for IP Traffic Flow Security", Don Fedyk, Eric Kinzie, 2021-05-21, This document describes managed objects for the 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. This is an unpublished work in progress. IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Jaehoon Jeong, 2021-10-09, 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), and then enumerates requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking. JSON Mail Access Protocol (jmap) -------------------------------- "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2021-07-27, This document specifies a data model for synchronizing calendar data with a server using JMAP. "S/MIME signature verification extension to JMAP", Alexey Melnikov, 2021-09-30, This document specifies an extension to JMAP for Mail (RFC 8621) for returning S/MIME signature verification status. "JMAP for Quotas", Rene Cordier, 2021-08-24, This document specifies a data model for handling quotas on accounts with a server using JMAP. "JSContact: A JSON representation of contact data", Robert Stepanek, Mario Loffredo, 2021-10-20, 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. "JSContact: Converting from and to vCard", Mario Loffredo, Robert Stepanek, 2021-10-20, This document defines how to convert contact information as defined in the JSContact [draft-ietf-jmap-jscontact] specification from and to vCard. "JMAP for Sieve Scripts", Kenneth Murchison, 2021-08-02, 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-Jorg Happel, 2021-10-20, This document specifies a data model for synchronizing task data with a server using JMAP. "JMAP Sharing", Neil Jenkins, 2021-06-06, This document specifies a data model for sharing data between users using JMAP. "JMAP Blob management extension", Bron Gondwana, 2021-10-16, 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, 2021-08-24, This document specifies an extension to JMAP for sending S/MIME signed and S/MIME encrypted messages. JSON Path (jsonpath) -------------------- "JSONPath: Query expressions for JSON", Stefan Gossner, Glyn Normington, Carsten Bormann, 2021-07-08, JSONPath defines a string syntax for identifying values within a JavaScript Object Notation (JSON) document. Contributing This document picks up the popular JSONPath specification dated 2007-02-21 and provides a normative definition for it. In its current state, it is a strawman document showing what needs to be covered. Comments and issues may be directed to this document's github repository (https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath- jsonpath). 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, 2020-06-10, This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without the need for a separately-established secure channel. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre- authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. "Best practices for password hashing and storage", Sam Whited, 2021-09-27, This document outlines best practices for handling user passwords and other authenticator secrets in client-server systems making use of SASL. "Channel Bindings for TLS 1.3", Sam Whited, 2021-10-18, This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, On Channel Binding. Furthermore it updates the "default" channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFC5801, RFC5802, RFC5929, and RFC8446. Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John Mattsson, Francesca Palombini, 2021-10-20, 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. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Certificate Management Protocol (CMP) Updates", Hendrik Brockhaus, David von Oheimb, 2021-07-09, This document contains a set of updates to the syntax and transport of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210 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' HTTP path segments. To properly differentiate the support of EnvelopedData instead of EncryptedValue, the CMP version 3 is introduced in case a transaction is supposed to use EnvelopedData. 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, Steffen Fries, David von Oheimb, 2021-07-09, 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 transport 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 special and complex use cases are supported as well, by features specified as recommended or optional. "Header Protection for S/MIME", Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov, 2021-07-26, S/MIME version 3.1 has introduced a feasible standardized option to accomplish Header Protection. However, few implementations generate messages using this structure, and several legacy and non-legacy implementations have revealed rendering issues at the receiving side. Clearer specifications regarding message processing, particularly with respect to header sections, are needed in order to resolve these rendering issues. Some mail user agents are also sending and receiving cryptographically-protected message headers using a different structure. In order to help implementers to correctly compose and render email messages with Header Protection, this document updates S/MIME Header Protection specifications with additional guidance on MIME format, sender and receiver processing. "Certificate Management Protocol (CMP) Algorithms", Hendrik Brockhaus, Hans Aschauer, Mike Ounsworth, John Gray, 2021-08-22, This document describes the conventions for using concrete cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. "S/MIME Example Keys and Certificates", Daniel Gillmor, 2021-08-05, The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. "Guidance on End-to-End E-mail Security", Daniel Gillmor, 2021-07-26, 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. "Update to the Object Identifier Registry for the PKIX Working Group", Russ Housley, 2021-10-07, RFC 7299 describes the object identifiers that were assigned by Public-Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2021-09-22, This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", Albert Cabellos-Aparicio, Damien Saucez, 2021-09-20, This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis], the protocol specifications. "LISP YANG Model", Vina Ermagan, AlbertoRodriguezNatal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino, 2021-08-24, 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). "The Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, David Meyer, Darrel Lewis, Albert Cabellos-Aparicio, 2020-11-18, This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. "Locator/ID Separation Protocol (LISP) Control-Plane", Dino Farinacci, Fabio Maino, Vince Fuller, Albert Cabellos-Aparicio, 2020-11-18, This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connecting EID addressable nodes of a LISP site, it the implementation and operational complexity of the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and RFC 6833. "LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal, Parantap Lahiri, 2021-09-19, This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2021-08-08, 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, 2021-07-26, 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, Victor Moreno, Fabio Maino, Dino Farinacci, 2021-07-25, 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, 2021-10-18, 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, 2021-09-19, This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. "Vendor Specific LISP Canonical Address Format (LCAF)", AlbertoRodriguezNatal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino Farinacci, 2021-03-30, This document describes a new LISP Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. "LISP Generic Protocol Extension", Fabio Maino, Jennifer Lemon, Puneet Agarwal, Darrel Lewis, Michael Smith, 2020-07-26, This document describes extensions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation and allow to introduce new protocol capabilities. "Publish/Subscribe Functionality for LISP", AlbertoRodriguezNatal, 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. "Locator/ID Separation Protocol (LISP) Map-Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 2021-08-31, This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocol (LISP) Map-Versioning", which is the initial experimental specifications of the mechanisms updated by this document. "LISP Control-Plane ECDSA Authentication and Authorization", Dino Farinacci, Erik Nordmark, 2021-08-30, 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. "Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations", Mohamed Boucadair, Christian Jacquenet, 2019-01-24, This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. "Network-Hexagons: H3-LISP GeoState & Mobility Network", sbarkai@gmail.com, Bruno Fernandez-Ruiz, Rotem Tamir, AlbertoRodriguezNatal, Fabio Maino, Albert Cabellos-Aparicio, Dino Farinacci, 2021-09-14, This document specifies the use of H3 and LISP for Geolocation Services. Geolocation Services utilize geospatial data for: Fresh HDMaps, Intelligent Driving, Cruise and Parking assists. Geospatial utilization is delivered using in-network compute for brokered verification, curation, and localization of data, using: - EID addressable geospatial-tiles abstraction of road-segments. - EID Interface for detections and uploads to the tile-contexts. - EID Routing-Sharing hazards, blockages, parking, road-inventory. - EID themed multicast channels per tile to subscribed clients. IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "Data Model for Static Context Header Compression (SCHC)", Ana Minaburo, Laurent Toutain, 2021-09-09, This document describes a YANG data model for the SCHC (Static Context Header Compression) compression and fragmentation rules. "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Sergio Aguilar, Laurent Toutain, Sandra Cespedes, Diego Torre, 2021-07-10, The Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification describes two mechanisms: i) an application header compression scheme, and ii) a frame fragmentation and loss recovery functionality. SCHC offers a great level of flexibility that can be tailored for different Low Power Wide Area Network (LPWAN) technologies. The present document provides the optimal parameters and modes of operation when SCHC is implemented over a Sigfox LPWAN. This set of parameters are also known as a "SCHC over Sigfox profile." "SCHC over NB-IoT", Edgar Ramos, Ana Minaburo, 2021-07-25, The Static Context Header Compression (SCHC) specification describes a header compression and fragmentation functionalities for LPWAN (Low Power Wide Area Networks) technologies. SCHC was designed to be adapted over any of the LPWAN technologies. This document describes the use of SCHC over the NB-IoT wireless access, and provides elements for an efficient parameterization. "LPWAN Static Context Header Compression (SCHC) Architecture", Alexander Pelov, Pascal Thubert, Ana Minaburo, 2021-05-18, This document defines the LPWAN SCHC architecture. "SCHC Compound ACK", Juan Zuniga, Carles Gomez, Sergio Aguilar, Laurent Toutain, Sandra Cespedes, Diego Torre, 2021-10-18, The present document describes an extension to the SCHC (Static Header Compression and Fragmentation) protocol [RFC8724]. It defines a SCHC Compound ACK message format, which is intended to reduce the number of downlink transmissions (i.e., SCHC ACKs) by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK). The message format is generic, and can be used for instance by any 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 IS-IS Protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Zhaohui Zhang, Ladislav Lhotka, 2019-10-15, This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. "YANG Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2019-10-17, This document defines a YANG data model that can be used to configure and manage OSPF. 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. "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2021-07-02, 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, 2021-08-16, This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing, as well as a YANG data module for the management of Signaling Maximum SID Depth (MSD) Using IS-IS. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2021-07-06, IGP protocols traditionally 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 proposes 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 the PCE discovery", Diego Lopez, Qin WU, Dhruv Dhody, Qiufang Ma, Daniel King, 2021-08-21, 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 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 PCEP security (e.g., Transport Layer Security (TLS), TCP Authentication Option (TCP-AO)) support capability. This document defines capability flag bits for 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 Key ID or Key Chain Name Sub-TLV to support TCP-AO security capability. RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the movement of the IANA "PCE Capability Flags" registry. "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Les Ginsberg, Huaimo Chen, Tony Przygienda, David Cooper, Luay Jalil, Srinath Dontula, Gyan Mishra, 2021-06-09, 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, 2021-10-20, 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, 2021-07-11, 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, 2021-09-27, 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, 2021-06-30, 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 Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston, 2021-04-27, This document specifies the extensions to OSPF that enables a router to signal to its neighbor the metric that the neighbor should use towards itself using link-local advertisement between them. The signaling of this reverse metric, to be used on the links towards itself, allows a router to influence the amount of traffic flowing towards itself and in certain use-cases enables routers to maintain symmetric metric on both sides of a link between them. "YANG Module for IS-IS Reverse Metric", Christian Hopps, 2021-01-05, This document defines a YANG module for managing the reverse metric extension to the the intermediate system to intermediate system routeing protocol. "Algorithm Related IGP-Adjacency SID Advertisement", Shaofu Peng, Ran Chen, Ketan Talaulikar, Peter Psenak, 2021-05-17, 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 "Flooding Topology Minimum Degree Algorithm", Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2021-06-01, This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. "Area Proxy for IS-IS", Tony Li, Sarah Chen, Vivek Ilangovan, Gyan Mishra, 2021-05-20, Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that would allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. "IS-IS Flood Reflection", Tony Przygienda, Chris Bowers, Yiu Lee, Alankar Sharma, Russ White, 2021-10-21, This document describes a backwards compatible, optional ISIS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection allows 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 they are used in the L2 SPF computation. However, they are not used for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties. As additional benefit, only those routers directly participating in flood reflection have to support the feature. This allows for the incremental deployment of scalable L1 transit areas in an existing network, without the necessity of upgrading other routers in the network. "IS-IS Topology-Transparent Zone", Huaimo Chen, Richard Li, Yi Yang, Yanhe Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani, 2021-09-29, 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 L2 Bundle Member Link Attributes in OSPF", Ketan Talaulikar, Peter Psenak, 2021-04-27, There are deployments where the Layer 3 interface on which OSPF operates is a Layer 2 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 about the bundle members is required. This document introduces the ability for OSPF to advertise the link attributes of layer 2 (L2) Bundle members. "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan, 2021-03-10, 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 obsoletes RFC 5316. "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", William Britto, Shraddha Hegde, Parag Kaneriya, Rejesh Shetty, Ron Bonica, Peter Psenak, 2021-05-14, An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute constraint-based paths. As currently defined, IGP Flex-Algorithm is used with Segment Routing (SR) data planes - SR MPLS and SRv6. Therefore, Flex-Algorithm cannot be deployed in the absence of SR. This document extends IGP Flex-Algorithm, so that it can be used for regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be deployed in any IP network, even in the absence of SR. "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee Lindem, Peter Psenak, 2021-09-13, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag 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 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, 2021-06-21, 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, 2021-07-12, 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 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. 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 Transport Instance Extensions", Acee Lindem, Yingzhen Qu, Abhay Roy, Sina Mirtorabi, 2021-05-21, 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 convenient to envision using 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 mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints", Shraddha Hegde, William Britto, Rejesh Shetty, Bruno Decraene, Peter Psenak, Tony Li, 2021-07-12, 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, 2021-10-09, 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, 2021-08-18, 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, 2021-08-18, 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]. Link State Vector Routing (lsvr) -------------------------------- "BGP Link-State Shortest Path First (SPF) Routing", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2021-07-01, Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm used by Internal Gateway Protocols (IGPs) such as OSPF. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. "Layer-3 Discovery and Liveness", Randy Bush, Rob Austein, Keyur Patel, 2021-10-14, In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. "Layer-3 Discovery and Liveness Signing", Randy Bush, Russ Housley, Rob Austein, 2021-10-14, The Layer-3 Discovery and Liveness protocol OPEN PDU may contain a public key and a certificate, which can be used to verify signatures on subsequent PDUs. This document describes two mechanisms based on digital signatures, one that is Trust On First Use (TOFU), and one that uses a trust anchor signture over the public key to provide authentication as well as session integrity. "L3DL Upper-Layer Protocol Configuration", Randy Bush, Keyur Patel, 2021-10-14, This document uses the Layer-3 Liveness and Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keranen, 2016-01-04, This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. "Alternative Elliptic Curve Representations", Rene Struik, 2021-06-09, 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 using existing implementations 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 ESP", Daniel Migault, Tobias Guggemos, 2021-09-28, This document describes a minimal IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. 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 environment while remaining interoperable with implementations of RFC 4303 ESP. In addition, this document also provides some considerations to implement minimal ESP in a constrained environment which includes limiting the number of flash writes, handling frequent wakeup / sleep states, limiting wakeup time, or reducing the use of random generation. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. RFC 4303 remains the authoritative description. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP DiffServ Aware Credit Window Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2021-07-29, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. "DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng, David Wiggins, Lou Berger, Stan Ratliff, 2021-06-21, 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, 2021-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. "DLEP IEEE 802.1Q Aware Credit Window Extension", David Wiggins, Lou Berger, 2021-07-29, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- "UDP Proxying Support for HTTP", David Schinazi, 2021-10-06, This document describes how to proxy UDP over HTTP. Similar to how the CONNECT method allows proxying TCP over HTTP, this document defines a new mechanism to proxy UDP. It is built using HTTP Extended CONNECT. "Requirements for a MASQUE Protocol to Proxy IP Traffic", Alex Chernyakhovsky, Dallas McCall, David Schinazi, 2021-08-27, There is interest among MASQUE working group participants in designing a protocol that can proxy IP traffic over HTTP. This document describes the set of requirements for such a protocol. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/ietf-wg-masque/draft-ietf- masque-ip-proxy-reqs. "Using Datagrams with HTTP", David Schinazi, Lucas Pardue, 2021-10-06, The QUIC DATAGRAM extension provides application protocols running over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts. This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3. It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. Additionally, this document defines how to convey datagrams over prior versions of HTTP. MBONE Deployment (mboned) ------------------------- "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2021-08-25, 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. "Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, 2021-07-11, This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. "Discovery Of Restconf Metadata for Source-specific multicast", Jake Holland, 2021-07-11, This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. "Circuit Breaker Assisted Congestion Control", Jake Holland, 2021-07-11, This document specifies Circuit Breaker Assisted Congestion Control (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate metadata about multicast channels from senders to intermediate network nodes or receivers. The circuit breaker behavior is defined as a supplement to receiver driven congestion control systems, to preserve network health if misbehaving or malicious receiver applications subscribe to a volume of traffic that exceeds capacity policies or capability for a network or receiving device. "Multicast On-path Telemetry Solutions", Haoyu Song, Mike McBride, Greg Mirsky, Gyan Mishra, Hitoshi Asaeda, Tianran Zhou, 2021-07-06, This document discusses the requirement of on-path telemetry for multicast traffic. The existing solutions are examined and their issues are identified. Solution modifications are proposed to allow the original multicast tree to be correctly reconstructed without unnecessary replication of telemetry information. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, Katriel Cohn-Gordon, 2021-10-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, 2021-10-04, The Messaging Layer Security (MLS) protocol [MLSPROTO] document has the role of defining a Group Key Agreement, all the necessary cryptographic operations, and serialization/deserialization functions necessary to create a scalable and secure group messaging protocol. The MLS protocol is meant to protect against eavesdropping, tampering, message forgery, and provide good properties such as forward-secrecy (FS) and post-compromise security (PCS) in the case of past or future device compromises. This document, on the other hand is intended to describe 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 mechanism that are part of the MLS protocol (ie. frequency of public encryption key rotation). The document also extends the guidance to 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, most will vastly influence the overall security guarantees that are achieved by the overall messaging system. This is especially true in case of active adversaries that are able to compromise clients, the delivery service or the authentication service. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2021-09-06, This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension. This specification updates RFCs 3264, 5888, and 7941. This specification obsoletes RFC 8843. Media OPerationS (mops) ----------------------- "Operational Considerations for Streaming Media", Jake Holland, Ali Begen, Spencer Dawkins, 2021-09-14, This document provides an overview of operational networking issues that pertain to quality of experience in streaming of video and other high-bitrate media over the Internet. "Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure", Renan Krishna, Akbar Rahman, 2021-07-28, A use case describing transmission of an application on the Internet that has several unique characteristics of Augmented Reality (AR) applications is presented for the consideration of the Media Operations (MOPS) Working Group. One key requirement identified is that the Adaptive-Bit-Rate (ABR) algorithms' current usage of policies based on heuristics and models is inadequate for AR applications running on the Edge Computing infrastructure. 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, 2021-08-20, 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. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2021-07-27, This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). "Refresh-interval Independent FRR Facility Protection", Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella, 2021-06-20, RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. "YANG Data Model for MPLS mLDP", Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura, Sowmya Krishnaswamy, 2021-09-08, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP data model augments the LDP data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "YANG Data Model for MPLS LDP", Syed Raza, Rajiv Asati, Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, 2020-03-20, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define Multipoint LDP (mLDP) model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "RFC6374 Synonymous Flow Labels", Stewart Bryant, George Swallow, Mach Chen, Giuseppe Fioccola, Greg Mirsky, 2021-03-05, RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as used in MPLS Transport Profile (MPLS-TP) networks. This document describes a method of extending RFC 6374 performance measurements from flows carried over MPLS-TP to flows carried over generic MPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multi-point to point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks. "OSPFv3 CodePoint for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro, Mustapha Aissaoui, 2021-09-23, IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" registries under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols. This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping TLV when the Interior Gateway Protocol (IGP) is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID sub-TLV indicates the use of IPv6. "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes", Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Xiaohu Xu, 2021-04-28, 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, 2021-09-09, 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, 2021-07-10, 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. "Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms", Deepti Rathi, Kapil Arora, Shraddha Hegde, Zafar Ali, Nagendra Nainar, 2021-10-20, 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. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, 2021-06-18, 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: * "2021-06-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log "RESTCONF Client and Server Models", Kent Watsen, 2021-05-18, 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: * "2021-05-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, 2021-06-18, 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: * "2021-06-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log "NETCONF Client and Server Models", Kent Watsen, 2021-05-18, 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: * "2021-05-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "A YANG Data Model for a Keystore", Kent Watsen, 2021-05-18, 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. 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 * "CCCC" --> 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: * "2021-05-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "YANG Data Types and Groupings for Cryptography", Kent Watsen, 2021-09-14, 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, 2021-05-18, 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. 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 this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2021-05-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "YANG Modules describing Capabilities for Systems and Datastore Update Notifications", Balazs Lengyel, Alexander Clemm, Benoit Claise, 2021-10-15, This document defines two YANG modules,"ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG related system capabilities for servers. The module can be used to report capability information from the server at run time or at implementation time, by making use of the YANG Instance Data File Format. The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to Subscription to YANG Notifications for Datastore Updates. "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael Scharf, 2021-05-18, 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. "YANG Groupings for HTTP Clients and HTTP Servers", Kent Watsen, 2021-05-18, 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: * "2021-05-18" --> the publication date of this draft 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, 2021-08-24, This draft extends 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, 2021-05-06, This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. "UDP-based Transport for Configured Subscriptions", Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente, 2021-10-21, 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. Network Modeling (netmod) ------------------------- "Comparison of NMDA datastores", Alexander Clemm, Yingzhen Qu, Jeff Tantsura, Andy Bierman, 2021-08-06, This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. "YANG Instance Data File Format", Balazs Lengyel, Benoit Claise, 2021-10-08, There is a need to document data defined in YANG models at design time, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. "YANG Module Versioning Requirements", Joe Clarke, 2021-07-06, 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, 2021-07-09, This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6991. "A YANG Grouping for Geographic Locations", Christian Hopps, 2021-06-17, This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to Earth or any other astronomical object. "Updated YANG Module Revision Handling", Robert Wilton, Reshad Rahman, Balazs Lengyel, Joe Clarke, Jason Sterne, 2021-07-12, 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 help and 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 8407 and RFC 8525. "YANG Semantic Versioning", Benoit Claise, Joe Clarke, Reshad Rahman, Robert Wilton, Balazs Lengyel, Jason Sterne, Kevin D'Souza, 2021-07-12, This document specifies a scheme and guidelines for applying a modified set of semantic versioning rules to revisions of YANG modules. Additionally, this document defines a revision-label for this modified semver scheme. "Self Describing Data Object Tags", Qin WU, Benoit Claise, Peng Liu, Zongpeng Du, Mohamed Boucadair, 2021-05-13, This document defines a method to tag data objects associated with operation and management data in YANG modules. This YANG data object tagging method can be used to classify data objects from different YANG modules and identify their characteristics data. It can also provide input, instruction, indication to selection filter, and filter queries of operational state on a server during a "pub/sub" service for YANG datastore updates. When the subscriptions of a particular subscriber to be fetched is very large, the amount of data to be streamed out to the destination can be reduced and only targeted to the characteristics data. These data object tags may be registered as well as assigned during the module definition, assigned by implementations, or dynamically defined and set by users. Network File System Version 4 (nfsv4) ------------------------------------- "Towards Remote Procedure Call Encryption By Default", Trond Myklebust, Chuck Lever, 2020-11-23, This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in-transit. The proposed mechanism interoperates with ONC RPC implementations that do not support it. This document updates RFC 5531. "RPC-over-RDMA Version 2 Protocol", Chuck Lever, David Noveck, 2021-07-06, 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. "Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2", Chuck Lever, 2021-07-06, This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 2. "Internationalization for the NFSv4 Protocols", David Noveck, 2021-09-26, This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. Network Management (nmrg) ------------------------- "Intent-Based Networking - Concepts and Definitions", Alexander Clemm, Laurent Ciavaglia, Lisandro Granville, Jeff Tantsura, 2021-09-02, Intent and Intent-Based Networking (IBN) are taking the industry by storm. At the same time, IBN-related terms are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "Policy." This document clarifies the concept of "Intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the RG, receiving reviews and explicit support from many members. It is published for informational purposes. "Intent Classification", Chen Li, Olga Havel, Adriana Olariu, Pedro Martinez-Julia, Jeferson Nobre, Diego Lopez, 2021-09-30, Intent is an abstract, high-level policy used to operate the network. Intent management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life-cycle. This document discusses mostly the concept of network intents, but other types of intents are also being considered. Specifically, it highlights stakeholder perspectives of intent, methods to classify and encode intent, the associated intent taxonomy, and defines relevant intent terms where necessary. This document provides a foundation for intent related research and facilitates solution development. This document is a product of the IRTF Network Management Research Group (NMRG). The document represents the consensus of the RG. During the document's lifecycle it received many positive expressions of support and detailed reviews beyond the authors. Only in the last call period it received more than 12 positive expressions of support and more than 5 detailed reviews. It is published for informational purposes. Individual Submissions (none) ----------------------------- "Mapping Between MIME Types, Content-Types, and URIs", Donald Eastlake, 2021-07-01, 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, 2021-10-10, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [https://NMA/]ark:[/]NAAN/Name[Qualifiers] an optional and mutable Name Mapping Authority (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending `?info', returns a metadata record that is both human- and machine-readable. The returned record contains core metadata and a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "An IPv4 Flowlabel Option", Thomas Dreibholz, 2021-09-06, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 2013-02-25, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Deterministic Route Redistribution into BGP", Enke Chen, Jenny Yuan, 2021-08-12, In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. In order to eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. We also recommend that the LOCAL_PREF value be reduced for the redistributed backup route, and be calculated automatically based on the administrative distance. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2021-09-06, 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, 2021-09-06, 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, 2021-09-06, 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, 2021-09-06, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Handle Resolution Option for ASAP", Thomas Dreibholz, 2021-09-06, 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, 2021-09-06, 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, 2021-09-06, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2021-04-27, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the Internet Engineering Task Force (IETF) for identifying, naming, assigning, and managing persistent resources in the legal domain. "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, 2021-08-09, 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, 2021-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, 2021-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, 2021-08-25, 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, 2021-09-06, 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, 2021-09-06, 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. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, 2021-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, 2021-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, 2021-05-10, This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address 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. "GSS-API pre-authentication for Kerberos", Alejandro Perez-Mendez, Rafael Marin-Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Luke Howard, 2021-09-23, This document describes a pre-authentication mechanism for Kerberos based on the Generic Security Service Application Program Interface (GSS-API), which allows a Key Distribution Center (KDC) to authenticate clients by using a GSS mechanism. "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, 2021-04-29, 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. "NAT traversal for LISP", Vina Ermagan, Dino Farinacci, Darrel Lewis, Fabio Maino, Marc Portoles-Comeras, Jesper Skriver, Chris White, Albert Bresco, Albert Cabellos-Aparicio, 2021-05-07, This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina Tsou, Simon Perreault, Jing Huang, 2013-09-16, An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. "The Link-Template HTTP Header Field", Mark Nottingham, 2021-08-31, This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. "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, 2021-06-14, 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, 2021-09-14, 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, 2021-08-05, 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, 2021-10-08, This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. "Multicast Traceroute for MVPNs", Robert Kebler, Pavan Kurapati, Saud Asif, Mankamana Mishra, Stig Venaas, 2021-06-14, Mtrace is a tool used to troubleshoot issues in a network deploying Multicast service. When multicast is used within a VPN service offering, the base Mtrace specification does not detect the failures. This document specifies a method of using multicast traceroute in a network offering Multicast in VPN service. "Remote APDU Call Secure (RACS)", Pascal Urien, 2021-10-02, 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, 2021-07-08, 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. "MPLS Payload Protocol Identifier", Xiaohu Xu, Hamid Assarpour, Shaowen Ma, Francois Clad, 2021-09-02, The MPLS label stack has no explicit protocol identifier field to indicate the protocol type of the MPLS payload. This document proposes a mechanism for containing a protocol identifier field within the MPLS packet, which is useful for any new encapsulation header (e.g., INT metadata) which may need to be encapsulated with an MPLS header. "Ideas for a Next Generation of the Reliable Server Pooling Framework", Thomas Dreibholz, 2021-09-06, 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, 2021-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. "Generic Fault-Avoidance Routing Protocol for Data Center Networks", Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish, 2021-05-29, This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. "SAML Profile for the Metadata Query Protocol", Ian Young, 2021-07-08, 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.16. "BGP Auto Discovery", Robert Raszuk, Jon Mitchell, Warren Kumari, Keyur Patel, John Scudder, 2021-10-13, This document describes a method for automating portions of a router's BGP configuration via discovery of BGP peers with which to establish further sessions from an initial "bootstrap" router. This method can apply for establishment of either Internal or External BGP peering sessions. "Passive DNS - Common Output Format", Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern, 2021-05-05, This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. "Just because it's an ID doesn't mean anything... at all...", Warren Kumari, 2021-06-15, Anyone can publish an Internet Draft. 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, 2021-10-04, This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. "A JSON Encoding for HTTP Field Values", Julian Reschke, 2021-04-22, This document establishes a convention for use of JSON-encoded field values in new HTTP fields. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, Reji Thomas, 2021-07-11, This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is key to deploying MPLS in data centers and enterprises. "Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)", Thomas Dreibholz, 2021-09-06, 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, 2021-10-12, 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, 2021-10-08, 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. "Application-Level Profile Semantics (ALPS)", Mike Amundsen, Leonard Richardson, Mark Foster, 2021-05-19, This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application- agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2021-06-25, This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version. "Egress Peer Engineering using BGP-LU", Hannes Gredler, Kaliraj Vairavakkalai, Chandrasekar R, Balaji Rajagopalan, Ebben Aries, Luyuan Fang, 2021-07-06, The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links. "Tetrys, an On-the-Fly Network Coding protocol", Jonathan Detchart, Emmanuel Lochin, Jerome Lacan, Vincent Roca, 2021-10-17, This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy [RFC8406] . This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay and loss-sensitive data over a lossy network. Tetrys can recover from erasures within an RTT-independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications. "TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor Dukhovni, Ash Wilson, 2021-05-02, 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. "LISP support for Multi-Tuple EIDs", AlbertoRodriguezNatal, Albert Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci, 2021-10-11, This document describes extensions for LISP to support EIDs based on tuples of multiple elements. "LISP Map Server Reliable Transport", Johnson Leong, Darrel Lewis, Balaji Venkatachalapathy, Chris Cassar, Isidor Kouvelas, Jesus Arango, 2021-04-26, 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. "SMTP Service Extension for Client Identity", William Storey, 2021-06-01, 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. "PCEP extensions for Distribution of Link-State and TE Information", Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra, Siva Sivabalan, 2021-08-25, 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. "MS-originated SMRs", AlbertoRodriguezNatal, Albert Cabellos-Aparicio, Vina Ermagan, Fabio Maino, Sharon Barkai, 2021-10-11, This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers to send SMR messages. This extension is intended to be used in some SDN deployments that use LISP as a southbound protocol with (P)ITRs that are compliant with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do not come from ETRs, but rather from a centralized controller that pushes the updates directly to the Mapping System. In such deployments, Map Servers will benefit from having a mechanism to inform directly (P)ITRs about updates in the mappings they are serving. Although implementations of this extension exist, this extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being documented for informational purposes. Newer implementations should look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP deployments. "Quantum Relief with TLS and Kerberos", Rick van Rein, Tom Vrancken, 2021-06-05, 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, 2021-10-08, 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. "PCEP Extensions for BIER-TE", Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang, 2021-07-12, Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE. "Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix", Naoki Matsuhira, 2021-06-17, 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, 2021-06-17, 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 Enhanced VPN Auto Discovery", Shunwan Zhuang, Zhenbin Li, Donald Eastlake, Lucy Yong, 2021-07-09, A variety of VPN technologies have been widely deployed to bear different services. As new applications develop, a requirement has been proposed for auto-discovery of Layer 3 Virtual Private Networks (L3VPN) and enhanced auto-discovery requirements for other VPN technologies that already have basic auto-discovery mechanisms. This document identifies some possible applications of these auto- discovery requirements and defines a new BGP NLRI, called the BGP- VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of BGP VPN instances. It also defines a new type of extended community, called the Import Route Target, which can be applied to auto- discovery mechanisms of multiple VPN technologies. "BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu, 2021-04-29, 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. "Using compression in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2021-08-25, This document describes a method for reducing the size of the IKEv2 messages by using lossless compression. Making IKEv2 messages smaller is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages. This document describes how compression is negotiated maintaining backward compatibility and how it is used in IKEv2. "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, 2021-10-21, 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. "TLS Extension for DANE Client Identity", Shumon Huque, Viktor Dukhovni, Ash Wilson, 2021-07-05, 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. "Mathematical Mesh 3.0 Part I: Architecture Guide", Phillip Hallam-Baker, 2021-09-20, 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, 2021-06-17, 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, 2021-06-17, 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, 2021-06-17, 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, 2021-06-17, 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, 2021-06-17, 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, 2021-06-17, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2021-06-17, 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, 2021-10-20, 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, 2021-09-04, 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 for the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets where the verification tag can not be checked. "A YANG model to manage the optical parameters for in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel, 2021-07-01, This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by means 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. "LISP Distinguished Name Encoding", Dino Farinacci, 2021-05-11, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2021-09-19, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2021-06-17, 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, 2021-06-02, 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, 2021-05-17, 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. "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", Donald Eastlake, Joe Abley, 2021-09-14, Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters 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. "BGP Flow Specification Version 2", Susan Hares, Donald Eastlake, 2021-07-26, BGP flow specification version 1 (RFC8955, RFC8956) describes the distribution of traffic filter policy (traffic filters and actions) which are distributed via BGP to BGP peers. Multiple applications utilize the BGP distributed traffic filter policy. These applications include: (1) mitigation of Denial of Service (DoS), (2) enabling of traffic filtering in BGP/MPLS VPNS, and(3)centralized traffic control for networks utilizing either SDN control of router firewall functions. During the deployment of BGP flow specification v1, the following issues were detected: 1) problems due to the lack of clear TLV encoding for rules for flow specifications, 2) desire to order filters rules, and 3) ordering of actions to provide deterministic actions. Version 2 of the BGP flow specification protocol addresses these features. BGP Flow Specification v2 is encapsulated in a different NLRI which encapsulates previous flow specification information. "BGP FlowSpec Extensions for Large Scale Prefix based Steering", Jie Dong, Zhenqiang Li, Liang Ou, Yujia Luo, 2021-07-12, This document describes a mechanism to use BGP FlowSpec RFC5575 as a scalable way of distributing prefix based traffic steering policies. The necessary extensions to BGP are also specified. "Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2021-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, 2021-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, 2021-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. "Formal SignWriting", Stephen Slevinski, 2021-07-31, Sutton SignWriting is the universal and complete solution for written sign language, ISO 15924 script code "Sgnw". It has been applied by a wide and deep international community of sign language users. Sutton SignWriting is an international standard for writing sign languages by hand or with computers. From education to research, from entertainment to religion, SignWriting has proven useful because people are using it to write signed languages. Formal SignWriting is one particular computerized design for Sutton SignWriting that envisions a sign as a two part word. Each word is written as a string of characters that can be recognized and processed by regular expressions. The design has been optimized for display, searching, sorting, text flow, and other character processing. Where as American Sign Language is a natural language, Formal SignWriting is a formal language. A formal language uses words and punctuation to form text. Each word is expressed as a string of characters. Well-formed words are governed by the structural rules of the grammar. A formal language is useful in mathematics, computer science, and linguistics. This memo defines a conceptual character encoding map for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "Compact Format of IKEv2 Payloads", Valery Smyslov, 2021-09-17, This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) messages by using an alternative format for IKE payloads. Standard format of many IKE payloads contains a lot of redundancy. This document takes advantage of this fact and specifies a way to eliminate some redundancy by using denser encoding. Reducing size of IKEv2 messages is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages. "MISP core format", Alexandre Dulaunoy, Andras Iklody, 2021-07-26, This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. "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, 2021-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). "BIER in BABEL", Zheng Zhang, Tony Przygienda, 2021-05-10, BIER introduces a novel multicast architecture. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per- flow state. Babel defines a distance-vector routing protocol that operates in a robust and efficient fashion both in wired as well as in wireless mesh networks. This document defines a way to carry necessary BIER signaling information in Babel. "Encapsulating IPsec ESP in UDP for Load-balancing", Xiaohu Xu, Shraddha Hegde, Boris Pismenny, Dacheng Zhang, Liang Xia, 2021-07-12, IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic. "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff Tantsura, 2021-06-30, 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, 2021-06-07, 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 routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as little 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 local IPv4 address shortage, while being transparent to the rest of the Internet. 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. "Network Service Header (NSH) Fixed-Length Context Header Allocation: Timestamp", Tal Mizrahi, Ilan Yerushalmi, David Melman, Rory Browne, 2021-08-12, The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. The allocation of this Context Header, i.e., its structure and semantics, has not been standardized. This memo presents an allocation for the fixed Context Headers of NSH, which incorporates the packet's timestamp, a sequence number, and a source interface identifier. Although the allocation that is presented in this document has not been standardized by the IETF it has been implemented in silicon by several manufacturers and is published here to allow other interoperable implementations and to facilitate debugging if it is seen in the network. "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue, Richard Bradbury, Sam Hurst, 2021-08-13, 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. "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, Zhong Xiang, Sandra Cespedes, 2021-08-21, 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, Sejun Lee, J., PARK, 2021-08-21, 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, 2021-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, 2021-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, 2021-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, 2021-08-08, Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. "NEAT Sockets API", Thomas Dreibholz, 2021-08-09, 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. "Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks", Zhiwei Yan, Jian Weng, Guanggang Geng, Jong-Hyouk Lee, Jaehoon Jeong, 2021-05-10, For Cooperative Adaptive Cruise Control (C-ACC), platooning and other typical use cases in Intelligent Transportation System (ITS), IPv6 communication between neighbor vehicles and between vehicle and server pose the following two issues: 1) how to discover a neighbor vehicle and the demanded service; and 2) how to discover the link- layer address and other metadata of the neighbor vehicle and selected server. This document presents a solution to these problems based on DNS-SD/mDNS [RFC6762][RFC6763]. "Performance Measurement (PM) with Alternate Marking Method in Service Function Chaining (SFC) Domain", Greg Mirsky, Giuseppe Fioccola, Tal Mizrahi, 2021-09-24, This document describes how the alternate marking method can be used as the efficient performance measurement method taking advantage of the actual data flows in a Service Function Chaining (SFC) domain. "BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Greg Mirsky, Gyan Mishra, Donald Eastlake, 2021-09-19, 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. "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak, 2021-06-23, 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. "Responder Initiated IP Addresses Update in MOBIKE", Valery Smyslov, 2021-05-25, IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in [RFC4555] allows peers to update their IP addresses without re- establishing IKE and IPsec Security Associations (SAs). In the MOBIKE protocol it is the initiator of the IKE SA, who is responsible for selecting new SA addresses and for initiating the IP addresses update procedure. This document presents an extension to the MOBIKE protocol that allows the responder to initiate IP address update. The document updates [RFC4555]. "BFD in Demand Mode over Point-to-Point MPLS LSP", Greg Mirsky, 2021-10-01, 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, 2021-06-11, 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 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 path-selection between the various additional-paths, which may tie-break on some arbitrary step like Router-Id. Some scenarios with a BGP-free core may benefit from having a mechanism, where egress-node can signal multiple-nexthops along with their relationship to ingress nodes. This document defines a new BGP attribute "MultiNexthop" that can be used for this purpose. This attribute can be used for both labeled and unlabled BGP families. For labeled-families, it is used for a different purpose in "downstream allocation" case than "upstream allocation" scenarios. "BGP signalled MPLS-namespaces", Kaliraj Vairavakkalai, Jeyananth Jeganathan, 2021-07-12, The MPLS-forwarding-layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. For some usecases like upstream-label-allocation, it is useful to be able to create virtual private MPLS-forwarding-layers over this shared MPLS-forwarding-layer. This allows installing deterministic private label-values in the private-FIBs created at nodes participating in this private MPLS forwarding-layer, while preserving the "locally significant" nature of the underlying shared 'public' MPLS-forwarding-layer. This specification describes the procedures to create such virtual private MPLS-forwarding layers (private MPLS-planes) using a new BGP family. And gives a few example use-cases on how this private forwarding-layers can be used. "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu, 2021-06-14, 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. "Interconnection of Segment Routing Sites - Problem Statement and Solution Landscape", Adrian Farrel, John Drake, 2021-05-19, Segment Routing (SR) is a forwarding paradigm for use in MPLS and IPv6 networks. It is intended to be deployed in discrete sites that may be data centers, access networks, or other networks that are under the control of a single operator and that can easily be upgraded to support this new technology. Traffic originating in one SR site often terminates in another SR site, but must transit a backbone network that provides interconnection between those sites. This document describes a mechanism for providing connectivity between SR sites to enable end-to-end or site-to-site traffic engineering. The approach described allows connectivity between SR sites, utilizes traffic engineering mechanisms (such as RSVP-TE or Segment Routing) across the backbone network, makes heavy use of pre-existing technologies, and requires the specification of very few additional mechanisms. This document provides some background and a problem statement, explains the solution mechanism, gives references to other documents that define protocol mechanisms, and provides examples. It does not define any new protocol mechanisms. "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Ali Sajassi, Gaurav Badoni, Priyanka Warade, S. Pasupula, John Drake, Jorge Rabadan, 2021-06-08, 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. "Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses", Roland Jesske, 2021-05-31, The Third Generation Partnership Project (3GPP) has identified cases where the private header field P-Visited-Network-ID SIP private header extensions, which is defined in RFC 7315 and updated by RFC 7976, needs to be included in SIP requests and responses. This document updates RFC 7976, in order to allow inclusion of the P- Visited-Network-ID header field in responses. "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri, 2021-09-28, This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network. "Reassignment of System Ports to the IESG", Mirja Kuehlewind, Sabrina Tanamal, 2020-02-10, In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate. "IPv6 Source Routing for ultralow Latency", Andreas Foglar, Mike Parker, Theodoros Rokkas, Mikhail Khokhlov, 2021-06-01, 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, 2021-07-07, 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. "Elliptic curve 2y^2=x^3+x over field size 8^91+5", Daniel Brown, 2021-09-30, Multi-curve elliptic curve cryptography with curve 2y^2=x^3+x/GF(8^91+5) hedges a risk of new curve-specific attacks. This curve features: isomorphism to Miller's curve from 1985; low Kolmogorov complexity (little room for embedded weaknesses of Gordon, Young--Yung, or Teske); similarity to a Bitcoin curve; Montgomery form; complex multiplication by i (Gallant--Lambert--Vanstone); prime field; easy reduction, inversion, Legendre symbol, and square root; five 64-bit-word field arithmetic; string-as-point encoding; and 34-byte keys. "A YANG Data Model for Client-layer Tunnel", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2021-09-07, 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. "YANG Model for QoS Operational Parameters", Aseem Choudhary, Ing-Wher Chen, 2021-07-12, This document describes a YANG model for Quality of Service (QoS) operational parameters. "DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet, Michael Behringer, 2021-07-12, 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. "AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc", Ronald Tse, Nick Nicholas, Paolo Brasolin, 2018-04-17, This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. "HTTP Live Streaming 2nd Edition", Roger Pantos, 2021-04-27, 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. "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", Qiao Xiang, Jensen Zhang, Franck Le, Y. Yang, Harvey Newman, 2021-07-12, As the data volume increases exponentially over time, data analytics is transiting from a single-domain network to a multi-domain, geo- distributed network, where different member networks contribute various resources, e.g., computation, storage and networking resources, to collaboratively collect, share and analyze extremely large amounts of data. Such a network calls for a resource orchestration framework that emphasizes the performance predictability of data analytics jobs, the high utilization of resources, and the autonomy and privacy of member networks. This document presents the design of Unicorn, a unified resource orchestration framework for multi-domain, geo-distributed data analytics, which uses the Application-Layer Traffic Optimization (ALTO) protocol as the key component for (1) allows member networks to provide accurate information on different types of resources; (2) keeps the private information of member networks; and (3) allows data analytics jobs to accurately describe their requirements of different types of resources. As a part of Unicorn, an ALTO extension for privacy-preserving interdomain information aggregation is also presented. "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin Cantrell, 2021-08-30, This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. "Health Check Response Format for HTTP APIs", Irakli Nadareishvili, 2021-10-16, This document proposes a service health check response format for HTTP APIs. "A feature freezer for the Concise Data Definition Language (CDDL)", Carsten Bormann, 2021-06-25, 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. It is now time to discuss thawing some of the concepts discussed here. A number of additional proposals have been added. "Simple Group Keying Protocol TRILL Use Profiles", Donald Eastlake, Dacheng Zhang, 2021-06-06, This document specifies use profiles for the application of the simple group keying protocol (SGKP) to multi-destination TRILL Extended RBridge Channel message security (RFC 7978) and TRILL over IP packet security (draft-ietf-trill-over-ip). "Application-Layer TLS", Owen Friel, Richard Barnes, Max Pritikin, Hannes Tschofenig, Mark Baugher, 2021-08-22, This document specifies how TLS and DTLS can be used at the application layer for the purpose of establishing secure end-to-end encrypted communication security. Encodings for carrying TLS and DTLS payloads are specified for HTTP and CoAP to improve interoperability. While the use of TLS and DTLS is straight forward we present multiple deployment scenarios to illustrate the need for end-to-end application layer encryption and the benefits of reusing a widely deployed and readily available protocol. Application software architectures for building, and network architectures for deploying application layer TLS are outlined. "LURK Protocol version 1", Daniel Migault, 2021-07-26, This document describes the Limited Usage of Remote Key (LURK) Architecture, the LURK Protocol as well as the LURK Extensions that enables remote interactions with cryptographic material. The specificities of these interactions are expected to be closely tied to some context and thus be defined in LURK Extensions. "LURK Extension version 1 for (D)TLS 1.2 Authentication", Daniel Migault, Ioana Boureanu, 2021-07-26, This document describes the LURK Extension 'tls12' which enables interactions between a LURK Client and a LURK Server in a context of authentication with (D)TLS 1.2. "IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2021-07-25, 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. "Unified Identifier in IPv6 Segment Routing Networks", Weiqiang Cheng, Greg Mirsky, Shaofu Peng, Liu Aihua, Gyan Mishra, 2021-09-25, Segment Routing architecture leverages the paradigm of source routing. It can be realized in a network data plane by prepending the packet with a list of instructions, a.k.a. segments. A segment can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment Routing can be applied in the MPLS data plane by encoding segments in the MPLS label stack. It also can be applied to the IPv6 data plane by encoding a list of segment identifiers in IPv6 Segment Routing Extension Header (SRH). This document extends the use of the SRH to unified segment identifiers encoded, for example, as MPLS label or IPv4 address, to compress the SRH, and support more detailed network programming and interworking between SR-MPLS and SRv6 domains. "Hybrid Two-Step Performance Measurement Method", Greg Mirsky, Wang Lingqiang, Guo Zhui, Haoyu Song, 2021-07-08, Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. "Synchronizing Internet Clock frequency protocol (sic)", Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib, 2021-04-29, Synchronizing Internet Clock (sic) Frequency specifies a new secure method to synchronize clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. This protocol is oriented to assure the quality of Internet Performance measurements, where they are frequently obtained as the difference of timestamps, hence frequency stability is needed. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error of fewer than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware. "Hierarchy of IP Controllers (HIC)", Zhenbin Li, Dhruv Dhody, Huaimo Chen, 2021-04-28, 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) 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, 2021-06-15, 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, 2021-07-26, 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, 2021-07-12, 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, 2021-07-09, 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, 2021-05-12, 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. "Multipath Extensions for QUIC (MP-QUIC)", Quentin De Coninck, Olivier Bonaventure, 2021-05-03, This document specifies extensions to the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. These extensions are compliant with the single-path QUIC design and preserve QUIC privacy features. Discussion about this draft is encouraged either on the QUIC IETF mailing list quic@ietf.org or on the GitHub repository which contains the draft: https://github.com/qdeconinck/draft-deconinck-multipath- quic. "mLDP Extensions for Multi-Topology Routing", IJsbrand Wijnands, Syed Raza, Mankamana Mishra, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko, 2021-06-29, 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. "Service Function discovery in fog environments", Carlos Bernardos, Alain Mourad, 2021-10-20, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments. "EVPN VXLAN Bypass VTEP", Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ White, 2021-07-06, 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, 2021-05-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. "Protecting EST Payloads with OSCORE", Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys, 2021-05-05, This document specifies public-key certificate enrollment procedures protected with lightweight application-layer security protocols suitable for Internet of Things (IoT) deployments. The protocols leverage payload formats defined in Enrollment over Secure Transport (EST) and existing IoT standards including the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR) and the CBOR Object Signing and Encryption (COSE) format. "Connected Identity for STIR", Jon Peterson, Chris Wendt, 2021-07-12, The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. "In-situ OAM raw data export with IPFIX", Mickey Spiegel, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, 2021-07-12, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses how In-situ Operations, Administration, and Maintenance (IOAM) information can be exported in raw, i.e. uninterpreted, format from network devices to systems, such as monitoring or analytics systems using IPFIX. "ICANN Registrar Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2021-07-06, 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. "Optimization of RWA Problem through OSNR", Shan Yin, Shanguo Huang, Shuang Zhou, Xiangkai Meng, Rong Ma, 2021-05-09, This documentary provides a kind of routing optimization method. In the basic of RWA solution method, both the output power of the route and the OSNR value of the optical signal noise ratio are considered. The selected optimal route has a lower bit error rate and the whole communication network performance is improved. "DLEP IEEE 802.1Q Aware Credit Window Extension", David Wiggins, Lou Berger, 2021-07-29, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. "RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks", Shanguo Huang, Shan Yin, Shuang Zhou, 2021-05-09, This documentary provides a routing, spectrum and core assignment method with the dividing frequency slots area for space division multiplexing elastic optical networks. This effective RSCA method to solve this problem better. The proposed method utilizes the Frequency Slots Area (FSA) concept and first-last fit policy of frequency slots assignment to have less spectrum fragments, lower crosstalk, smaller traffic blocking probability and higher spectrum resource utilization. "IMAP Service Extension for Client Identity", Deion Yu, 2021-05-25, 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. "SRv6 across SDWAN paths", Linda Dunbar, Mehmet Toy, 2021-05-18, This document describes the mechanism of steering packets across SDWAN segments based on the metadata carried by the SRv6 packets. Some of the SDWAN segments are untrusted networks, and some are private networks. The goal is to achieve the optimal E2E quality. "Segment Routing Traffic Accounting Counters", Clarence Filsfils, Zafar Ali, Martin Horneffer, Dan Voyer, Muhammad Durrani, Robert Raszuk, 2021-10-17, Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. Traffic accounting plays a critical role in network operation. A traffic account solution is required for SR networks that provides the necessary functionality without creating any additional per SR path states in the fabric. This document describes counters for traffic accounting in SR networks. "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen, Evgeny Alekseev, 2021-09-02, This document specifies three new cipher suites, two new signature algorithms, seven new supported groups and two new certificate types for the Transport Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms (called GOST algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations. This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups and certificate types. "The IPv6 Tunnel Payload Forwarding (TPF) Option", Ron Bonica, Yuji Kamite, Luay Jalil, Yifeng Zhou, Gang Chen, 2021-07-26, 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, 2021-08-05, 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. "PCE Controlled ID Space", Cheng Li, Mach Chen, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2021-08-22, 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 mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID or any other to-be-defined identifier that can be allocated by a PCE. "IGP Extensions for Scalable Segment Routing based Enhanced VPN", Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Lee JooHeon, Stewart Bryant, 2021-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. This document specifies the IGP mechanisms with necessary extensions to advertise the associated topology and resource attributes for scalable Segment Routing (SR) based VTNs. Each VTN can have a customized topology and a set of network resources allocated from the physical network. Multiple VTNs may shared the same topology, and multiple VTNs may share the same set of network resources on some network segments. A group of resource-aware SIDs are allocated for each VTN. This allows flexible combination of the network topology and network resource attributes to build a relatively large number of VTNs with a small number of logical topologies. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This document also describes the mechanisms of using dedicated VTN-ID in the data plane instead of the per-VTN resource-aware SIDs to further reduce the control plane overhead. "TLS 1.3 Authentication and Integrity only Cipher Suites", Nancy Cam-Winget, Jack Visoky, 2021-06-17, This document defines the use of HMAC-only cipher suites for TLS 1.3, which provides server and optionally mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but is presented here to enable interoperable implementation of a reduced security mechanism that provides authentication and message integrity without supporting confidentiality. "TEAP Update and Extensions for Bootstrapping", Eliot Lear, Owen Friel, Nancy Cam-Winget, Dan Harkins, 2021-08-24, In certain environments, in order for a device to establish any layer three communications, it is necessary for that device to be properly credentialed. This is a relatively easy problem to solve when a device is associated with a human being and has both input and display functions. It is less easy when the human, input, and display functions are not present. To address this case, this memo specifies extensions to the Tunnel Extensible Authentication Protocol (TEAP) method that leverages Bootstrapping Remote Secure Key Infrastructures (BRSKI) in order to provide a credential to a device at layer two. The basis of this work is that a manufacturer will introduce the device and the local deployment through cryptographic means. In this sense the same trust model as BRSKI is used. "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark, 2021-05-25, This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. "Security Policy Translation in Interface to Network Security Functions", Jaehoon Jeong, Patrick Lingga, Jinhyuk Yang, Chaehong Chung, 2021-08-21, This document proposes a scheme of security policy translation (i.e., Security Policy Translator) 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 mapping 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, 2021-09-12, 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, 2021-07-26, This document describes the LURK Extension 'tls13' which enables interactions between a LURK client and a LURK server in a context of authentication with (D)TLS 1.3. "Multiple ALTO Resources Query Using Multipart Message", Jingxuan Zhang, Y. Yang, 2021-07-12, Many ALTO use cases involve multiple ALTO information resources like different network maps, cost maps and property maps to achieve their own specific goals. To make the ALTO client query them one by one is not only inefficient but also error-prone. The inconsistent responses can be performed because of the unstable communication environment, and finally conduct the unexpected traffic optimization. Further more, some ALTO information resources may have correlation, which means one's input parameters may depends on another one's response. To address those issues, some advanced query schema is required. This document proposes an ALTO extension to support the multiple ALTO resources query in the single request using the HTTP multipart message and the existing JSON query languages. "Terminology for Cryptoassets", Hirotaka Nakajima, Masanori Kusunoki, Keiichi Hida, Yuji Suga, Tatsuya Hayashi, 2021-07-04, This document provides terminology used in cryptoassets. "MPLS Extension Header", Haoyu Song, Zhenbin Li, Tianran Zhou, Loa Andersson, Zhaohui Zhang, 2021-07-10, Motivated by the need to support multiple in-network services and functions in an MPLS network, this document describes a generic and extensible method to encapsulate extension headers into MPLS packets. The encapsulation method allows stacking multiple extension headers and quickly accessing any of them as well as the original upper layer protocol header and payload. We show how the extension header can be used to support several new network applications and optimize some existing network services. "Flexible Session Protocol", Jun-an Gao, 2021-10-17, FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some secure hash or 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 "Implementation notes for RFC7991,", Henrik Levkowetz, 2021-09-16, This memo documents issues and observations found while implementing RFC 7991. Individual notes are organised into separate sections, depending on their character. "Subject Identifiers for Security Event Tokens", Annabelle Backman, Marius Scurtescu, 2021-05-24, Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the "sub_id" JSON Web Token (JWT) claim. "YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng, Qiufang Ma, 2021-06-23, 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]. "The Decentralized Identifier (DID) in the DNS", Alexander Mayrhofer, Dimitrij Klesev, Markus Sabadello, 2021-06-09, This document specifies the use of the URI Resource Record Type to publish Decentralized Identifiers (DIDs) in the DNS. "The Multihash Data Format", Juan Benet, Manu Sporny, 2021-08-15, 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, 2021-10-01, 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. "IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)", Carlos Bernardos, Alain Mourad, 2021-09-09, Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. In the current version, mechanisms based on piggybacking options on IPv6 neighbor discovery are explored. New IPv6 neighbor discovery options are defined. Additional mechanisms will be explored in future releases of this document. "Discovery of OSCORE Groups with the CoRE Resource Directory", Marco Tiloca, Christian Amsuess, Peter van der Stok, 2021-07-12, 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, 2021-05-11, 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 Flow Data Telemetry using Packet Marking", Haoyu Song, Greg Mirsky, Clarence Filsfils, Ahmed Abdelsalam, Tianran Zhou, Zhenbin Li, Jongyoon Shin, Kyungtae Lee, 2021-07-09, The document describes a packet-marking variation of the Postcard- Based Telemetry (PBT), referred to as PBT-M. Similar to the instruction-based PBT (i.e., IOAM DEX), PBT-M does not carry the telemetry data in user packets but send the telemetry data through a dedicated packet. Unlike the instruction-based PBT, PBT-M does not require an extra instruction header. PBT-M raises some unique issues that need to be considered. This document formally describes the high level scheme and cover the common requirements and issues when applying PBT-M in different networks. PBT-M is complementary to the other on-path telemetry schemes such as IOAM. "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola, Yisong Liu, Shinyoung Lee, Mauro Cociglio, Weidong Li, 2021-07-11, This document extends the IPv6 Alternate Marking Option, defined in IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark], to provide the enhanced capabilities and allow advanced functionalities. "Terminology, Power, and Exclusionary Language in Internet-Drafts and RFCs", Mallory Knodel, Niels ten Oever, 2021-08-23, 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. This document represents the opinion of the authors and does not have IETF consensus. "Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) for SRv6 SID Allocation and Distribution.", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2021-08-27, 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 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) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of P2MP LSPs", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2021-08-27, 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. "BMP for BGP Route Leak Detection", Yunan Gu, China Telecom, Di Ma, Shunwan Zhuang, 2021-07-10, According to Route-Leak Problem Definition [RFC7908], Route leaks refer to the case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to prevent the happening of BGP [RFC4271] route leaks. However, the real-time route leak detection if any occurs is important as well, and serves as the basis for leak mitigation. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks at the prefix level. "Architecture for Use of BGP as Central Controller", Yujia Luo, Liang Ou, Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li, 2021-08-26, 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, 2021-04-29, 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-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. "Multicast/BIER As A Service", Zhaohui Zhang, Eric Rosen, Daniel Awduche, Liang Geng, Greg Shepherd, 2021-10-14, 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. "EVPN ELAN FRR Loop Prevent label", Haibo Wang, Donald Eastlake, Tong Zhu, 2021-07-11, This document describes how to use Fast Re-Route (FRR) labels avoid traffic loop in CE failures when deploying FRR protection in EVPN scenarios. "AC-Aware Bundling Service Interface in EVPN", Ali Sajassi, Patrice Brissette, Mankamana Mishra, Samir Thoria, Jorge Rabadan, John Drake, 2021-07-11, 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, 2021-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. "In-situ Flow Information Telemetry", Haoyu Song, Fengwei Qin, Huanan Chen, Jaewhan Jin, Jongyoon Shin, 2021-10-21, As network scale increases and network operation becomes more sophisticated, traditional Operation, Administration and Maintenance (OAM) methods, which include proactive and reactive techniques, running in active and passive modes, are no longer sufficient to meet the monitoring and measurement requirements. Data-plane on-path telemetry techniques which provide high-precision flow insight and real-time issue notification are emerging to support suitable quality of experience for users and applications, and network fault or deficiency identification. Centering on the new data-plane on-path telemetry techniques, this document outlines a high-level framework to provide an operational environment that utilizes these techniques to enable the collection and correlation of performance measurement information from the network. The framework identifies the components that are needed to coordinate the existing protocol tools and telemetry mechanisms, and addresses key deployment challenges for flow-oriented on-path telemetry techniques, especially in carrier networks. The framework is informational and intended to guide system designers attempting to apply the referenced techniques as well as to motivate further work to enhance the ecosystem. "YANG Data Model for OSPF SRv6", Zhibo Hu, Xuesong Geng, Syed Raza, Yingzhen Qu, Acee Lindem, 2021-07-02, 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. "SRv6 and MPLS interworking", Swadesh Agrawal, Zafar Ali, Clarence Filsfils, Dan Voyer, Zhenbin Li, 2021-08-22, 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, 2021-08-15, 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, 2021-07-12, 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, AlbertoRodriguezNatal, Marc Portoles-Comeras, Fabio Maino, Sanjay Hooda, 2021-07-26, 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, Henri Manson, 2021-08-06, SASL and GSS-API are used for authentication in many application protocols. This specification extends them to allow credentials of a home realm 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, 2021-10-18, 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, 2021-06-15, 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. "Considerations for Large Authoritative DNS Servers Operators", Giovane Moura, Wes Hardaker, John Heidemann, Marco Davids, 2021-08-23, Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible advice to operators when configuring authoritative DNS servers. It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration, anycasted service. This document is not an IETF consensus document: it is published for informational purposes. "MessageVortex Protocol", Martin Gwerder, 2021-10-03, The MessageVortex (referred to as Vortex) protocol achieves different degrees of anonymity, including sender, receiver, and third-party anonymity, by specifying messages embedded within the existing transfer protocols, such as SMTP or XMPP, sent via peer nodes to one or more recipients. The protocol outperforms others by decoupling the transport from the final transmitter and receiver. No trust is placed into any infrastructure except for that of the sending and receiving parties of the message. The creator of the routing block (routing block builder; RBB) has full control over the message flow. Routing nodes gain no non-obvious knowledge about the messages even when collaborating. While third-party anonymity is always achieved, the protocol also allows for either sender or receiver anonymity. "The Universal IPv6 Configuration Option", Timothy Winters, Ole Troan, 2021-07-12, One of the original intentions for the IPv6 host configuration, was to configure the network-layer parameters only with IPv6 ND, and use service discovery for other configuration information. Unfortunately that hasn't panned out quite as planned, and we are in a situation where all kinds of configuration options are added to RAs and DHCP. This document proposes a new universal option for RA and DHCP in a self-describing data format, with the list of elements maintained in an IANA registry, with greatly relaxed rules for registration. "The Multibase Data Format", Juan Benet, Manu Sporny, 2021-08-15, 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. "Cryptographic Hyperlinks", Manu Sporny, Leonard Rosenthol, 2021-05-02, When using a hyperlink to fetch a resource from the Internet, it is often useful to know if the resource has changed since the data was published. Cryptographic hashes, such as SHA-256, are often used to determine if published data has changed in unexpected ways. Due to the nature of most hyperlinks, the cryptographic hash is often published separately from the link itself. This specification describes a data model and serialization formats for expressing cryptographically protected hyperlinks. The mechanisms described in the document enables a system to publish a hyperlink in a way that empowers a consuming application to determine if the resource associated with the hyperlink has changed in unexpected ways. "Generic Multi-Access (GMA) Encapsulation Protocol", Jing Zhu, Satish Kanugovi, 2021-10-21, 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. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new light weight and flexible encapsulation protocol for this need. 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. "Mathematical Mesh 3.0 Part X: The Trust Mesh", Phillip Hallam-Baker, 2021-08-05, This paper extends Shannon's concept of a 'work factor' as applied to evaluation of cryptographic algorithms to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best-known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models and peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis demonstrates that both approaches have limitations and that in certain applications, a blended model is superior to either by itself. The final section of the paper describes a proposal to realize this blended model using the Mathematical 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-trust.html. "IPv6 Neighbor Discovery Unicast Lookup", Pascal Thubert, Eric Levy-Abegnoli, 2021-09-27, This document updates RFC 8505 in order to enable unicast address lookup from a 6LoWPAN Border Router acting as an Address Registrar. "General Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw, 2021-10-11, 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. "MPLS Extension Header Architecture", Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant, 2021-10-06, Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes an architecture for EHs and what actions an EH capable Label Switching Router (LSR) takes when finding or not finding an EH in the packet. Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology. It uses label stack entries that are pre-pended to either the EH or the ACH which in turn is pre-pended to the payload. The label stack entries are used to identify the forwarding actions by each LSR. Actions may include pushing, swapping or popping the labels, and using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. The extension headers are carried after the MPLS Label Stack, and the presence of EHs are indicated in the label stack by an Extension Header Indicator (EHI). "Options for MPLS Extension Header Indicator", Haoyu Song, Zhenbin Li, Tianran Zhou, Loa Andersson, 2021-07-02, The intention of this document is to enumerate and describe the candidate schemes that can be used to indicate the presence of the MPLS extension header(s) following the MPLS label stack. 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 header indicator. "IKEv2 Optional SA&TS Payloads in Child Exchange", Sandeep Kampati, Wei Pan, Paul Wouters, Bharath Meduri, chenmeiling, 2021-07-25, 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. "MPLS Label Operations in MPLS EH capable networks", Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant, 2021-10-06, Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes the operations on the MPLS label stack when an EH is found in the packet. "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip Hallam-Baker, 2021-09-20, This document describes the 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. 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, 2021-09-20, This document describes the Data At Rest Encryption (DARE) Envelope and Container syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Container syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Containers 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, 2021-05-25, 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. "Transport parameters for 0-RTT connections", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom Jones, Christian Huitema, 2021-10-19, QUIC 0-RTT transport features currently focuses on egress traffic optimization. This draft proposes a QUIC extension that improves the performance of ingress traffic. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Sun Kj, Hyunsik Yang, Jangwon Lee, Tran Ngoc, Younghan Kim, 2021-08-09, This draft describes considerations for benchmarking network performance in containerized infrastructures. In the containerized infrastructure, Virtualized Network Functions(VNFs) are deployed on an operating-system-level virtualization platform by abstracting the user namespace as opposed to virtualization using a hypervisor. Leveraging this, the system configurations and networking scenarios for benchmarking will be partially changed by the way in which the resource allocation and network technologies are specified for containerized VNFs. In this draft, we compare the state of the art in a container networking architecture with networking on VM-based virtualized systems and provide several test scenarios for benchmarking network performance in containerized infrastructures. "Support for Path MTU (PMTU) in the Path Computation Element (PCE) communication Protocol (PCEP).", Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, 2021-10-21, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. This document specify the extension to PCE communication protocol (PCEP) to carry path (MTU) in the PCEP messages. "A YANG Data Model for Segment Routing (SR) Policy and SRv6 support in Path Computation Element Communications Protocol (PCEP)", Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor, 2021-10-21, This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). "Composite Signatures For Use In Internet PKI", Mike Ounsworth, Massimiliano Pala, 2021-07-12, With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite signature data. This document defines the structures CompositeSignatureValue, and CompositeParams, which are sequences of the respective structure for each component algorithm. This document also defines processes for generating and verifying composite signatures. This document makes no assumptions about what the component algorithms are, provided that their algorithm identifiers and signature generation and verification processes are defined. "A YANG Data Model for Network Interconnect Tester Management", Vladimir Vassilev, 2021-07-11, This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. "SRv6 Midpoint Protection", Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong Geng, Yisong Liu, 2021-07-12, The current local repair mechanism, e.g., TI-LFA, allows local repair actions on the direct neighbors of the failed node to temporarily route traffic to the destination. This mechanism could not work properly when the failure happens in the destination point or the link connected to the destination. In SRv6 TE, the IPv6 destination address in the outer IPv6 header could be the dedicated endpoint of the TE path rather than the destination of the TE path. When the endpoint fails, local repair couldn't work on the direct neighbor of the failed endpoint either. This document defines midpoint protection, which enables the direct neighbor of the failed endpoint to do the function of the endpoint, replace 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, Na Kim, 2021-05-23, 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. "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde, 2021-10-21, 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. "Autonomic setup of fog monitoring agents", Carlos Bernardos, Alain Mourad, 2021-05-17, The concept of fog computing has emerged driven by the Internet of Things (IoT) due to the need of handling the data generated from the end-user devices. The term fog is referred to any networked computational resource in the continuum between things and cloud. In fog computing, functions can be stiched together composing a service function chain. These functions might be hosted on resources that are inherently heterogeneous, volatile and mobile. This means that resources might appear and disappear, and the connectivity characteristics between these resources may also change dynamically. This calls for new orchestration solutions able to cope with dynamic changes to the resources in runtime or ahead of time (in anticipation through prediction) as opposed to today's solutions which are inherently reactive and static or semi-static. A fog monitoring solution can be used to help predicting events so an action can be taken before an event actually takes place. This solution is composed of agents running on the fog nodes plus a controller hosted at another device (running in the infrastructure or in another fog node). Since fog environments are inherently volatile and extremely dynamic, it is convenient to enable the use of autonomic technologies to autonomously set-up the fog monitoring platform. This document aims at presenting this use case as well as specifying how to use GRASP as needed in this scenario. "In Situ OAM Profiles", Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel, Tianran Zhou, Jennifer Lemon, 2021-08-19, In Situ Operations, Administration and Maintenance (IOAM) is used for monitoring network performance and for detecting traffic bottlenecks and anomalies. This is achieved by incorporating IOAM data into in- flight data packets. This document introduces the concept of use case-driven IOAM profiles. An IOAM profile defines a use case or a set of use cases for IOAM, and an associated set of rules that restrict the scope and features of the IOAM specification, thereby limiting it to a subset of the full functionality. The motivation for defining profiles is to limit the scope of IOAM features, allowing simpler implementation, verification, and interoperability testing in the context of specific use cases that do not require the full functionality of IOAM. "Enhanced AS-Loop Detection for BGP", Huanan Chen, Di Ma, Yunan Gu, Shunwan Zhuang, Haibo Wang, 2021-07-09, Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. "Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann, 2021-07-12, 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. "The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA's Profile for Delivery of Certificates, CRLs, and Symmetric Keys to Clients", Michael Jenkins, Sean Turner, 2020-09-08, This document specifies protocol interfaces profiled by the US NSA (United States National Security Agency) for NSS (National Security System) servers that provide public key certificates, CRLs (Certificate Revocation Lists), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as SODP (Secure Object Delivery Protocol) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include: EST (Enrollment over Secure Transport) and its extensions as well as CMC (Certificate Management over CMS (Cryptographic Message Syntax)). This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP 800- 59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. "Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS)", Matt Campagna, Eric Crockett, 2021-09-02, Hybrid key exchange refers to executing two independent key exchanges and feeding the two resulting shared secrets into a Pseudo Random Function (PRF), with the goal of deriving a secret which is as secure as the stronger of the two key exchanges. This document describes new hybrid key exchange schemes for the Transport Layer Security 1.2 (TLS) protocol. The key exchange schemes are based on combining Elliptic Curve Diffie-Hellman (ECDH) with a post-quantum key encapsulation method (PQ KEM) using the existing TLS PRF. "Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Zhong Xiang, 2021-08-21, 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. "Registry Lock Extension for the Extensible Provisioning Protocol (EPP)", Ulrich Wisser, 2021-07-07, This extensions defines an additional protective layer for changes to domain [RFC5731], host [RFC5732] and contact [RFC5733] objects managed through EPP. EPP allows changes to objects only by the sponsoring client. EPP objects are usually managed by the sponsoring client on behalf of the sponsoring clients customers. All of these interactions are ususally fully automated. In case of a system breach, there is no protection in EPP to changes to any object by the intruder. This extension defines a protective layer that aims to break automated changes and work flows by requiring manual intervention. The actual form of manual intervention is out-of-scope for this document. By whom and how changes can be made is up to the registry and registrars to decide. "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip Hallam-Baker, 2021-08-05, 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 IX Security Considerations", Phillip Hallam-Baker, 2021-09-20, 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-security.html. "Mathematical Mesh 3.0 Part V: Protocol Reference", Phillip Hallam-Baker, 2021-09-20, 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, 2021-08-05, 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. "Programming Methodology Framework aka PMF", Alexandre Dulaunoy, Andras Iklody, 2021-10-01, This document describes the Programming Methodology Framework also known under the PMF methodology. The methodology is based on the manifesto written by Zed A. Shaw [PROGRAMMING-MF-MANIFESTO] which describes a natural approach to software engineering with a strong focus on the act of programming. The PMF methodology uses a soft naming to allow for a non-partisan reference to official engineering or project documents describing one of the most used software engineering methodologies. "ARP/ND Synching And IP Aliasing without IRB", Yubao Wang, Zheng Zhang, 2021-09-01, This draft discusses serveral signalling modes of EVPN Signalled L3VPNs. EVPN Signalled L3VPNs are used to improve L3VPNs for some new use cases. Then it discusses which style of RT-5 routes can be selected for these new use cases, and why they are selected. "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2021-08-12, This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit Discovery. This is a robust method for Path MTU Discovery (PMTUD) that uses the UDP Options Packetization Layer (PL). It allows a datagram application that uses this PL, to discover the largest size of datagram that can be sent across a network path. "IPv6 Neighbor Discovery on Wireless Networks", Pascal Thubert, 2021-05-17, This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media. "Public Key Authenticated Encryption for JOSE: ECDH-1PU", Neil Madden, 2021-05-06, This document describes the ECDH-1PU public key authenticated encryption algorithm for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but adds an additional ECDH key agreement between static keys of the sender and recipient. This additional step allows the recipient to be assured of sender authenticity without requiring a nested signed-then-encrypted message structure. "IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)", Parag Kaneriya, Rejesh Shetty, Shraddha Hegde, Ron Bonica, 2021-08-30, Source nodes can use the IPv6 Compressed Routing Header (CRH) to steer packets through a specified path. This document defines IS-IS extensions that support the CRH. "Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao, 2021-10-21, 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. "The Cooperative Communication Method of the Converged Multi-media Wireless Resource Management Network", Yi Liu, 2021-05-16, This paper describes a cooperative communication method of theconverged multi-media wireless resource management network.It can maximize the utilization of heterogeneous network resources and optimize the access to wireless resources of the network in the form of Mesh, which solves the problem of collaborative wireless resource management in multi-media converged networks. Through the overall consideration of multi-media converged networks including wired network, wireless network, broadband network, and narrowband network, joint access control and resource scheduling for network devices with different characteristics in heterogeneous networks are realized. "Design of the native Cyberspace Map", Jilong Wang, Miao Congcong, Changqing An, Shuying Zhuang, 2021-06-15, 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, 2021-10-21, 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. "IS-IS Flooding Congestion Control", Bruno Decraene, Chris Bowers, Jayesh J, Tony Li, Gunter Van de Velde, Guillaume Solignac, 2021-07-12, This document proposes a mechanism to adjust IS-IS flooding speed between two adjacent routers by adjusting the sender flooding speed to the capability of the receiver. This helps improving the flooding throughput, reducing LSPs losses and retransmissions due to receiver overload, and avoiding manual tuning of flooding parameters by the network operator. This document defines a new TLV for Hello messages. This TLV may carry a set of parameters indicating the performance capacity to receive LSPs. "Preferred Path Loop-Free Alternate (pLFA)", Stewart Bryant, Uma Chunduri, Toerless Eckert, 2021-06-27, Fast re-route (FRR) is a technique that allows productive forwarding to continue in a network after a failure has occurred, but before the network has has time to re-converge. This is achieved by forwarding a packet on an alternate path that will not result in the packet looping. Preferred Path Routing (PPR) provides a method of injecting explicit paths into the routing protocol. The use of PPR to support FRR has a number of advantages. This document describes the advantages of using PPR to provide a loop-free alternate FRR path, and provides a framework for its use in this application. "PCEP Operational Clarification", Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni, 2021-08-19, This document provides clarity about how PCEP operates and hence to facilitates interoperability between different equipment vendors. The content of this document has been compiled based on the feedback from several multi-vendor interop exercises. Several constructs are introduced, such as the LSP-DB and the ASSO-DB. "The Some Congestion Experienced ECN Codepoint", Jonathan Morton, Peter Heist, Rodney Grimes, 2021-05-17, 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. "Carrying SID Algorithm information in PCE-based Networks.", Alexej Tokar, Samuel Sidor, Shaofu Peng, Siva Sivabalan, Tarek Saad, Shuping Peng, Mahendra Negi, 2021-10-04, The Algorithm associated with a prefix Segment-ID (SID) defines the path computation Algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the Algorithm associated with each prefix SID used in PCE-computed paths, as well as signalling a specific SID algorithm as a constraint to the PCE. "Using GOST ciphers in ESP and IKEv2", Valery Smyslov, 2021-08-25, This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols. The transforms are based on Russian cryptographic standard algorithms (GOST) in a Multilinear Galois Mode (MGM). "BMP Extension for Path Status TLV", Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf, 2021-04-27, 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 BGP path before and after being processed by the BGP best-path selection algorithm. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-lucente-grow-bmp-tlv-ebit [I-D.lucente-grow-bmp-tlv-ebit]. "Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework", Marco Tiloca, Rikard Hoeglund, Ludwig Seitz, Francesca Palombini, 2021-07-12, 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 to 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, 2021-04-29, This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path. "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu, 2021-04-29, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for protecting the ingress node of a Segment Routing (SR) tunnel or path. "Test Tools for IoT DDoS vulnerability scanning", Sorin Faibish, Mashruf Chowdhury, 2021-06-18, 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. "Distributed SFC control for fog environments", Carlos Bernardos, Alain Mourad, 2021-07-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 introduces the role of SFC pseudo- controller and specifies solutions to select and initialize such new logical function. "Encapsulation of Path Segment in SRv6", Cheng Li, Weiqiang Cheng, Yongqing Zhu, Zhenbin Li, Dhruv Dhody, 2021-05-08, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an IPv6 data plane, called SRv6. In some use-cases such as end-to-end SR Path Protection and Performance Measurement (PM), an SRv6 path needs to be identified. An SRv6 Path Segment can be used for identifying an SRv6 path. This document defines a P-flag in the Segment Routing Header to indicate the appearence of SRv6 Path Segment. "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, 2021-09-09, 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 "PCEP extensions for p2mp sr policy", Hooman Bidgoli, Dan Voyer, Saranya Rajarathinam, Ehsan Hemmati, Tarek Saad, Siva Sivabalan, 2021-05-25, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. "Describing Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2021-05-05, 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. "Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/ Traceroute", Nagendra Nainar, Carlos Pignataro, Zafar Ali, Clarence Filsfils, Tarek Saad, 2021-05-18, RFC8402 introduces Segment Routing architecture that leverages source routing and tunneling paradigms and can be directly applied to the Multi Protocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with Segment Routing header. SR architecture defines different types of segments with different forwarding semantics associated. SR can be applied to the MPLS directly and to IPv6 dataplane using a new routing header. RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. Various SIDs are proposed as part of SR architecture with different associated instructions that raises a need to come up with new Target FEC Stack Sub-TLV for each such SIDs. This document defines a new Target FEC Stack Sub-TLV that is used to validate the instruction associated with any SID. "PCEP Extension for SR-MPLS Entropy Label Position", Quan Xiong, Shaofu Peng, Fengwei Qin, 2021-07-07, This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks. "EVPN LOOP PREVENTION BASED ON TRUSTED MAC", GuoLiang Liu, Haibo Wang, Tong Zhu, 2021-07-11, A principal feature of EVPN is the ability to support MAC duplication detection based on MAC Mobility Extended Community. This draft specifies a mechanism of valid loop prevention based on trusted MAC to avoid servce interruption of the specifed source or destination MAC address due to "black-holing". "Definition of new tags for relations between RFCs", Mirja Kuehlewind, Suresh Krishnan, 2021-07-12, An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases. "Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish, Philip Shilane, 2021-06-18, 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, 2021-10-19, 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. "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", Deb Cooley, 2021-01-20, This document defines a base profile for TLS protocol versions 1.2 and 1.3, as well as DTLS protocol versions 1.2 and 1.3 for use with the United States Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. "New Cryptographic Algorithms for HIP", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2021-08-02, This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. "Additional Parameter sets for LMS Hash-Based Signatures", Scott Fluhrer, Quynh Dang, 2021-06-02, 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. "A YANG Module for uCPE management.", Dmytro Shytyi, Laurent Beylier, Luigi Iannone, 2021-09-09, This document provides a YANG data model for uCPE management (VYSM) and definition of the uCPE equipment. The YANG Model serves as a base framework for managing an universal Customer-Premises Equipment (uCPE) subsystem. The model can be used by a Network Orchestrator. "SRv6 NET-PGM extension: Insertion", Clarence Filsfils, Pablo Camarillo, John Leddy, Dan Voyer, Satoru Matsushima, Zhenbin Li, 2021-07-06, 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. "Oblivious DNS Over HTTPS", Eric Kinnear, Patrick McManus, Tommy Pauly, Tanya Verma, Christopher Wood, 2021-09-02, This document describes an extension to DNS Over HTTPS (DoH) that allows hiding client IP addresses via proxying encrypted DNS transactions. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental extension is developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. "Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security", Valery Smyslov, 2021-08-02, 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) 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 the same protection against quantum computers, but unlike the [RFC8784] solution it covers the initial IKEv2 SA too. "Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2021-04-30, 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. "ACME for Subdomains", Owen Friel, Richard Barnes, Tim Hollebeek, Michael Richardson, 2021-06-23, 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 certificate policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay Hooda, 2021-04-23, This draft defines how to register/retrieve default-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, 2021-10-15, This document describes a mechanism to solve an existing issue with Longest Prefix Match (LPM), that exists where an operator domain is divided into multiple areas or levels where summarization is utilized. This draft addresses a fail-over issue related to a multi areas or levels domain, where a link or node down event occurs resulting in an LPM component prefix being omitted from the FIB resulting in black hole sink of routing and connectivity loss. This draft introduces a new control plane convergence signaling mechanism using a negative prefix called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the RIB that the event has occurred to force immediate control plane convergence. "Lzip Compressed Format and the application/lzip Media Type", Antonio Diaz, 2021-04-24, 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 Lempel-Ziv-Markov chain-Algorithm (LZMA) stream format, chosen to maximize safety and interoperability. Lzip can achieve higher compression ratios than gzip. This document describes the lzip format and registers a media type and content encoding to be used when transporting lzip-compressed content via Multipurpose Internet Mail Extensions (MIME). "The Computerate Specifying Paradigm", Marc Petit-Huguenin, 2021-10-11, 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, 2021-06-10, 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 specification defines four new cipher suites and seven new signature schemes based on GOST R 34.12-2015, GOST R 34.11-2012 and GOST R 34.10-2012 algorithms. This document does not imply IETF endorsement of the cipher suites. "Advertising p2mp policies in BGP", Hooman Bidgoli, Dan Voyer, Andrew Stone, Rishabh Parekh, Serge Krier, Arvind Venkateswaran, 2021-10-07, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document specifies a new BGP SAFI with a new NLRI in order to advertise P2MP policy from a controller to a set of nodes. This document introduces three new route types within this NLRI, one for P2MP policy and its candidate paths that need to be programmed on the Root node, one for the replication segment incoming SID which uniquely will identify the cross connect and another for each outgoing interface that the packets get replicated to. The last two route types are forwarding instructions that needs to be programmed on the Root, and optionally on Transit and Leaf nodes. It should be noted that this document does not specify how the Root and the Leaves are discovered on the controller, it only describes how the P2MP Policy and Replication Segments are programmed from the controller to the nodes. "Compressed Routing Header (CRH) Helper Option", Xing Li, Congxiao Bao, Eddie Ruan, Ron Bonica, 2021-10-11, This document defines the IPv6 Compressed Routing Header (CRH) Helper option. When a source node sends a packet with a CRH, it can use the CRH Helper option to provide additional information to downstream nodes. "EVPN-VPWS Seamless Integration with L2VPN VPWS", Patrice Brissette, Ali Sajassi, LucAndre Burdet, Wen Lin, Jorge Rabadan, Jim Uttaro, Dan Voyer, Iman Ghamari, Eddie Leyton, Bin Wen, Voitek Kozak, 2021-07-12, 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 flexible-crossconnext (FXC) service basis. This document specifies control-plane and forwarding behaviors. "Architecture Discussion on SRv6 Mobile User plane", Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali, 2021-05-06, SRv6 mobile user plane is standardized in IETF. It accomplishes the mobile user-plane functions in a simple, flexible and scalable manner, by utilizing the network programming nature of SRv6. It leverages common native IPv6 data plane and creates interoperable overlays with underlay optimization. This document discusses the solution approach and its architectural benefits of common data plane across domains and across overlay/ underlay. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6", Xueshun Wang, Jinyou Dai, Jianhua Liu, Feng Zhang, 2021-04-25, This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks. "State-updating mechanism in RSVP-TE for MPLS network", Jun Gao, Jinyou Dai, 2021-05-02, RSVP-TE has the following advantages: source routing capability, and the ability to reserve resources hop by hop along the LSP path. RSVP takes a "soft state" approach to manage the reservation state in routers and hosts. The use of 'Refresh messages' to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling. This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages. These extension present no backwards compatibility issues. "Predictable Multipath TCP (MPTCP) extension", Qian Wu, Hewu Li, Qi Zhang, Jun Liu, 2021-09-13, Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session, which is quite suitable for integrated network scenarios where multiple paths almost always exist. However, link handover and link on-off switching happen frequently in network systems that integrate different systems (especially the systems that continually move), which defeats the quality of MPTCP connections. Information about the link handover and on-off switching in above- mentioned scenarios can be predicted in advance, but MPTCP is not capable of utilizing the prediction information. This document suggests MPTCP be extended with the capacity of obtaining and utilizing the prediction information. Furthermore, the document describes one possible way to enhance MPTCP with prediction information, which proposes a modified MPTCP scheduler utilizing link on-off prediction information. "Color Operation with BGP Label Unicast", Louis Chan, 2021-08-26, This document specifies how to carry colored path advertisement via an enhancement to the existing protocol BGP Label Unicast. It would allow backward compatibility with RFC8277. The targeted solution is to use stack of labels advertised via BGP Label Unicast 2.0 for end to end traffic steering across multiple IGP domains. The operation is similar to Segment Routing. This proposed protocol will convey the necessary reachability information to the ingress PE node to construct an end to end path. Another two problems addressed here are the interworking with Flex-Algo, and the MPLS label space limit problem. Please note that there is a major change of protocol format starting from version 01 draft. Except the optional BGP capability code, these rest of BGP attributes used in this draft are defined in previous RFC or in use today in other scenario. "Performance Measurement for Geneve", Xiao Min, Greg Mirsky, Santosh Pallagatti, 2021-05-17, 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, 2021-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, Zhong Xiang, Zeung Kim, 2021-08-21, This document proposes a Context-Aware Navigation Protocol (CNP) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CNP aims at the enhancement of driving safety through a light-weight driving information sharing method. The CNP protocol uses an IPv6 Neighbor Discovery (ND) option to convey driving information such as a vehicle's position, speed, acceleration/deceleration, and direction, and a driver's driving action (e.g., braking and accelerating). "Basic Support for Security and Privacy in IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, J., PARK, 2021-08-21, This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks. "Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang, Aijun Wang, Shunwan Zhuang, 2021-07-12, BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956]propogates 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. "Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic", Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch, 2021-07-26, CCNx utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes and/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 [IEEE.754.2019]. This document updates _CCNx messages in TLV Format_ (RFC8609) to specify this alternative encoding. "IETF Network Slice YANG Data Model", Xufeng Liu, Jeff Tantsura, Igor Bryskin, Luis Contreras, Qin WU, Sergio Belotti, Reza Rokui, 2021-07-09, This document describes a YANG data model for managing and controlling IETF network slices, defined in [I-D.ietf-teas-ietf-network-slices]. "IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Controllers", Luis Contreras, Shunsuke Homma, Jose Ordonez-Lucena, Jeff Tantsura, Krzysztof Szarkowicz, 2021-07-12, This document analyses the needs of potential customers of network slices realized with IETF techniques in several use cases, identifies the functionalities for the North Bound Interface (NBI) of an IETF Network Slice Controller to satisfy such requests. "IS-IS Flooding Scale Considerations", Les Ginsberg, Peter Psenak, Marek Karasek, Acee Lindem, Tony Przygienda, 2021-07-08, Link State PDU flooding rates in use 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 issues associated with increasing flooding rates and some recommended practices which allow faster flooding rates to be used safely. "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, 2021-07-12, 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 relies on resource observation for the Constrained Application Protocol (CoAP), with Clients and Resource Servers observing a Token Revocation List on the Authorization Server. Resulting unsolicited notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. "Use of ALTO for Determining Service Edge", Luis Contreras, Danny Perez, Christian Rothenberg, Sabine Randriamasy, 2021-07-12, 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, 2021-06-15, 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. "User Plane Message Encoding", Tetsuya Murakami, Satoru Matsushima, Kentaro Ebisawa, Pablo Camarillo, Ravi Shekhar, 2021-09-02, This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network. "Deadline-aware Transport Protocol", Yong Cui, Zhiwen Liu, Hang Shi, Jie Zhang, Kai Zheng, Wei Wang, 2021-07-25, 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. "SR-MPLS Data Plane with IPv6 Control Plane", Clarence Filsfils, Francois Clad, Ketan Talaulikar, 2021-05-24, This document reminds the existence of the "Segment Routing (SR) MPLS data-plane with IPv6 control-plane" solution that is mature from a standardization, productization and commercial deployment viewpoint. "Abstract", Yuying Chen, Jiagui Xie, Zhiping Li, Hongyan Liu, 2021-04-25, 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. "Segment Routing Mapped To IPv6 (SRm6)", Ron Bonica, Shraddha Hegde, Yuji Kamite, Andrew Alston, Daniam Henriques, Luay Jalil, Joel Halpern, Jen Linkova, Gang Chen, 2021-09-27, This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 is a Segment Routing (SR) solution that supports a wide variety of use-cases while complying with IPv6 specifications. SRm6 is optimized for ASIC-based routers that operate at high data rates. "Data Aggregation in IPv6-based Vehicular Networks", Zhiwei Yan, Jong-Hyouk Lee, Jaehoon Jeong, Yong-Jin Park, Hidenori Nakazato, 2021-05-10, Considering the large-scale but small-sized information exchange in the vehicular information network, this draft document aims at outlining the requirements to support the data aggregation in vehicular networks based on the concept of Information-centric networking (ICN), in order to make the information retrieval and dissemination in an efficient way. "Delivering Functions over Networks: Traffic and Performance Optimization for Edge Computing using ALTO", Shu Yang, Laizhong Cui, Mingwei Xu, Huaimo Chen, Xiuli Xia, 2021-08-09, As the rapid development of internet, massive data are produced. Service providers typically need to deploy services near the edge networks to better satisfy user_s demand. In order to obtain better quality of the networks, computing functions and user traffic need to be scheduled properly. However, it is challenging to efficiently schedule resources among the distributed edge servers because of the lack of network information, such as network topology, traffic distribution, link delay/bandwidth and utilization/capability of computing servers. In this standard, we employed the ALTO protocol to help deliver functions and schedule traffic at the edge computing platform. This protocol supplied information of multiple resources for the distributed edge computing platform, thus enhancing the efficiency of function delivery in edge computing platform. "Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)", Laura Corcoran, Michael Jenkins, 2021-05-24, The United States Government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPSec. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. "RPKI validated cache Update in SLURM over HTTPs (RUSH)", Di Ma, Hanbing Yan, Melchior Aelmans, 2021-05-13, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-21, 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, 2021-06-13, 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, 2021-08-05, 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, 2021-06-21, 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, 2021-07-25, 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, 2021-07-30, This document defines a stateless and scalable solution to achieve network slicing with SRv6. "SRv6 vSID: Network Programming extension for variable length SIDs", Bruno Decraene, Robert Raszuk, Zhenbin Li, Cheng Li, 2021-09-08, This document proposes an extension to Segment Routing IPv6 (SRv6) Network Programming to allow for SRv6 Segment Identifier (SID) of smaller variable length. The use of smaller SRv6 SID reduces the size the SRv6 Header (SRH). This reduces the overhead for both the traffic volume and the network processor. It is a straightforward extension to the SRv6 Network Programming model and its SRH encapsulation. "Point-to-Multipoint Transport Using Chain Replication in Segment Routing", Yimin Shen, Zhaohui Zhang, Rishabh Parekh, Hooman Bidgoli, Yuji Kamite, 2021-06-14, This document specifies a point-to-multipoint (P2MP) transport mechanism based on chain replication. It can be used in segment routing to achieve traffic optimization for multicast. "Lightweight Authorization for Authenticated Key Exchange.", Goeran Selander, John Mattsson, Malisa Vucinic, Michael Richardson, Aurelio Schellenbaum, 2021-05-04, This document describes a procedure for augmenting the authenticated Diffie-Hellman key exchange EDHOC with third party assisted authorization targeting constrained IoT deployments (RFC 7228). "Using GOST algorithms in IKEv2", Valery Smyslov, 2021-08-25, This document defines a set of cryptographic transforms for use in the Internet Key Exchange version 2 (IKEv2) protocol. The transforms are based on Russian cryptographic standard algorithms (GOST). "Scalability Considerations for Enhanced VPN (VPN+)", Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Jim Guichard, Gyan Mishra, Fengwei Qin, 2021-07-11, Enhanced VPN (VPN+) aims to provide enhancements to existing VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. VPN+ could be used to provide network slicing, and may also be of use in more generic scenarios, such as enterprise services which have demanding requirement. With the requirement for VPN+ services increase, scalability would become an important factor for the deployment of VPN+. This document describes the scalability considerations in the control plane and data plane to enable VPN+ services, some optimization mechanisms are also described. "Carrying Virtual Transport Network Identifier in IPv6 Extension Header", Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma, Gyan Mishra, 2021-09-08, 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 physical network. A VTN can be used as the underlay for one or a group of overlay VPNs 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 performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN Resource ID, which is used to identify the set of network resources allocated to a VTN for packet processing. The procedure for processing the VTN option is also specified. "BGP Extension for SR-MPLS Entropy Label Position", Liu Yao, Shaofu Peng, 2021-08-30, This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. "New UUID Formats", Brad Peabody, Kyzer Davis, 2021-10-07, This document presents new time-based UUID formats which are suited for use as a database key. A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs. "Quic Timestamps For Measuring One-Way Delays", Christian Huitema, 2021-09-12, 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. "Metadata in SR-MPLS Service Programming", Liu Yao, 2021-09-15, This document proposes methods to carry metadata in SR service programming with SR-MPLS data plane. "Adaptive Subscription to YANG Notification", Qin WU, Wei Song, Peng Liu, Qiufang Ma, Wei Wang, 2021-07-10, This document defines a YANG data model and associated mechanism enabling subscriber's adaptive subscriptions to a publisher's event streams with various different period intervals to report updates. Applying these elements allows servers automatically adjust the volume of telemetry traffic and rate of traffic sent from publisher to the receivers. "Data Export Notification Capability", Qin WU, Qiufang Ma, Peng Liu, Wei Wang, 2021-08-30, This document proposes a YANG module for data export notification capabilities which augments System-Capabilities model defined in [I- D.netconf-notification-capabilities] and provides additional data export attributes associated with system capabilities for transport specific Notification. This YANG module can be used by the client to learn capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. "Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2021-05-24, 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, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2021-06-16, 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 unware 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 satifying 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. "Announcing Supported Authentication Methods in IKEv2", Valery Smyslov, 2021-08-31, 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. "Indicators of Compromise (IoCs) and Their Role in Attack Defence", Kirsty Paine, Ollie Whitehouse, James Sellwood, 2021-07-12, Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This draft reviews the fundamentals, opportunities, operational limitations, and best practices of IoC use. It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies - both for the IoCs' initial discovery and their use in detection - and provides a foundation for new approaches to operational challenges in network security. "Conveying Transceiver-Related Information within RSVP-TE Signaling", Julien Meuric, Esther Le Rouzic, Luay Alahdab, Gabriele Galimberti, 2021-07-12, 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. "Inserting, Processing And Deleting IPv6 Extension Headers", Ron Bonica, Tatuya Jinmei, 2021-08-30, This document provides guidance regarding the processing, insertion, and deletion of IPv6 extension headers. It updates RFC 8200. "Bootstrapped TLS Authentication", Owen Friel, Dan Harkins, 2021-07-09, This document defines a TLS extension that enables a server to prove to a client that it has knowledge of the public key of a key pair where the client has knowledge of the private key of the key pair. Unlike standard TLS key exchanges, the public key is never exchanged in TLS protocol messages. Proof of knowledge of the public key is used by the client to bootstrap trust in the server. The use case outlined in this document is to establish trust in an EAP server. "A User-Focused Internet Threat Model", Dominique Lazanski, 2021-07-06, 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-01 which is a comprehensive document that lists threats, attack vectors, examples and considerations for designing protocols, as well as draft-taddei-smart- cless-introduction-02 which lays out security concerns, capabilities and limitations for endpoints in general and draft-mcfadden-smart- endpoint-taxonomy-for-cless-01 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, 2021-07-12, 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, 2021-09-15, 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, 2021-09-15, 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, 2021-09-15, This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. "Use cases of Application-aware Networking (APN) in Edge Computing", Peng Liu, Zongpeng Du, Shuping Peng, Zhenbin Li, 2021-06-01, The ever-emerging new services are imposing more and more highly demanding requirements on the network. However, the current deployments could not fully accommodate those requirements due to limited capabilities. For example, it is difficult to utilize the traditional centralized deployment mode to meet the low-latency demand of some latency-sensitive applications. Moreover, the total amount of centralized service data is growing exponentially, which brings great pressure on the network bandwidth. There has been a clear trend that decentralized sites comprising of computing and storage resources are deployed at various locations to provide services. In particular, when the sites are deployed at the network edge, i.e. the Edge Computing, it can better handle the business needs of the users nearby, which provides the possibilities to provide differentiated network and computing services. In order to achieve the full benefits of the edge computing, it actually implies a precondition that the network should be aware of the applications' requirements in order to steer their traffic to the network paths that can satisfy their requirements. Application-aware networking (APN) aims to accommodate the edge services' needs, fully releasing the benefits of the edge computing. This document describes the various application scenarios in edge computing to which the APN can be beneficial, including augmented reality, cloud gaming and remote control, which empowers the video business, users interaction business and user-device interaction business. In those scenarios, APN can identify the specific requirements of edge computing applications on the network, process close to the users, provide SLA guaranteed network services such as low latency and high reliability. "An Architecture for Network Function Interconnect", Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene, 2021-06-30, 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. "Distributed SFC control operation", Carlos Bernardos, Alain Mourad, 2021-09-09, 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, 2021-09-09, 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, 2021-09-09, 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 based VTN", Yongqing Zhu, Jie Dong, Zhibo Hu, 2021-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 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 topology of a VTN can be defined using Flex-Algo. In some network scenarios, each VTN can be associated with a unique Flex- Algo, and the set of network resources of the VTN can be instantiated as sub-interfaces or member links of the L3 interfaces. This document describes the mechanisms to build the SR based VTNs using SR Flex-Algo and IGP L2 bundle with minor extensions. "BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks", Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li, 2021-07-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. For 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. "Security Considerations for Protocol Designers", Dominique Lazanski, 2021-07-06, 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-03. 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. "Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic", Zongpeng Du, Peng Liu, 2021-07-11, 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 aggregation in the intermediate nodes. This document introduces the problem of micro- bursts in layer3 network, and proposed a method to decrease the micro-bursts in layer3 network for low-latency traffic. "BCP72 - A Problem Statement", Mark McFadden, 2021-07-12, RFC3552/BCP72 describes an Internet Threat model that has been used in Internet protocol design. More than seventeen years have passed since RFC3552 was written and the structure and topology of the Internet have changed. With those changes comes a question: has the Internet Threat Model changed? Or, is the model described in RFC3552 still mostly accurate? This draft attempts to describe a non- exhaustive list of changes in the current threat environment. It finds that there are both qualitative and quantitative differences from the environment described in RFC3552 and is intended as input to the IAB program on the Internet threat model started in 2020. "Forwarding Layer Problem Statement", Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm, 2021-06-28, 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", Chunshan Xiong, Yunfei Zhang, Richard Yang, Gang Li, Yixue Lei, Yunbo Han, 2021-07-12, With the quick deployment of 5G networks in the world, cloud based interactive services such as clouding gaming have gained substantial attention and are regarded as potential killer applications. 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 bandwidth and delay experienced by a mobile and wireless user can be dynamic, as a function of many factors, and unhandled changes can substantially compromise users' QoE. In this document, we investigate network-aware applications (NAA), which realize cloud based interactive services with improved QoE, by efficient utilization of 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 information, the applications can then adapt key control knobs such as media codec scheme, encapsulation and application logical function to minimize QoE deduction. Based on the evaluations, we discuss how MoWIE can be a systematic extension of the ALTO protocol, to expose more lower-layer and finer grain network dynamics. "SPAKE2+, an Augmented PAKE", Tim Taubert, Christopher Wood, 2021-07-06, 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. "Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk, 2021-07-12, This document specifies the operations performed by a forward-proxy or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a single request, sent by a CoAP client over unicast, and distributes the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends these responses to the CoAP client, in a way that allows the client to distinguish the responses and their origin servers through addressing information. This document updates RFC7252. "BGP Well Known Large Community", Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley, 2021-09-08, A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities. "Strong Assertions of IoT Network Access Requirements", Brendan Moran, Hannes Tschofenig, 2021-05-25, The Manufacturer Usage Description (MUD) specification describes the access and network functionality required a device to properly function. The MUD description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link a SUIT manifest to a MUD file offering a stronger binding between the two. "Supporting Multi-domain Use Cases with ALTO", Danny Perez, Christian Rothenberg, Qiao Xiang, Y. Yang, Borje Ohlman, Sabine Randriamasy, Farni Boten, Luis Contreras, Jingxuan Zhang, Kai Gao, 2021-07-12, The goal of this document is to summarize current standardization efforts in the IETF ALTO working group to support important multi- domain use cases and show how they can benefit from network information exposure using ALTO. Besides, key design requirements of network information exposure to support multi-domain use cases are also presented along with information about novel mechanisms and abstractions to improve the base ALTO framework in multi-domain scenarios. "Abstract", Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li, 2021-06-21, 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, 2021-05-26, This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone environment to provide much of the ASTM and FAA envisioned Network Remote ID (N-RID) functionality. This crowd sourced B-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. "DNS Server Selection: DNS Server Information with Assertion Token", Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair, 2021-10-07, The document defines a mechanism that is meant to communicate DNS resolver information to DNS clients for use as a criteria for server selection decisions. Such an information that is cryptographically signed to attest its authenticity is used for the selection of DNS resolvers. Typically, evaluating the resolver information and the signatory, DNS clients with minimal or no human intervention can select the DNS servers for resolving domain names. This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS- over-HTTPS, or DNS-over-QUIC) servers that are either public resolvers or discovered in a local network. "Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication", Alexey Melnikov, 2021-05-24, This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. This specification also gives an example of how TOTP (RFC 6238) can be used as the second factor. "Sieve: Internationalized Email", Stephan Bosch, 2021-05-25, This document defines an extension to the Sieve language called "eai" which adds full support for internationalized email. "Real-time text solutions for multi-party sessions", Gunnar Hellstrom, 2021-06-20, This document specifies methods for Real-Time Text (RTT) media handling in multi-party calls. The main discussed transport is to carry Real-Time text by the RTP protocol in a time-sampled mode according to RFC 4103. The mechanisms enable the receiving application to present the received real-time text media, separated per source, in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment. A number of alternative methods for providing the multi-party negotiation, transmission and presentation are discussed and a recommendation for the main ones is provided. The main solution for SIP based centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP stream. Alternative methods using a single RTP stream and source identification inline in the text stream are also described, one of them being provided as a lower functionality fallback method for endpoints with no multi-party awareness for RTT. Bridging methods where the text stream is carried without the contents being dealt with in detail by the bridge are also discussed. Brief information is also provided for multi-party RTT in the WebRTC environment. The intention is to provide background for decisions, specification and implementation of selected methods. "Per-Node Capabilities for Optimum Operational Data Collection", Benoit Claise, Munish Nayyar, Adithya Sesani, 2021-07-12, This document proposes a YANG module that provides per-node capabilities for optimum operational data collection. This YANG module augments the YANG Modules for describing System Capabilities and YANG-Push Notification capabilities. This module defines augmented nodes to publish the metadata information specific to YANG node-identifier as per ietf-system- capabilities datatree. Complementary RPCs, based on the same node capabilities, simplify the data collection operations. "UAS Operator Privacy for RemoteID Messages", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2021-10-07, This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. "Secure UAS Network RID and C2 Transport", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2021-10-21, This document provides the mechanisms for secure transport of Unmanned Aircraft System (UAS) Network Remote ID (N-RID) and Command- and-Control (C2) messaging. Both HIP and DTLS based methods are described. "QUIC Version Aliasing", Martin Duke, 2021-05-13, 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. "Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery Smyslov, 2021-05-17, This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS protocols such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- over-QUIC (DoQ). "LTP Fragmentation", Fred Templin, 2021-10-11, 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 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. "BGP Maximum Prefix Limits Inbound", Melchior Aelmans, stucchi-lists@glevia.com, Job Snijders, 2021-06-16, This document describes mechanisms to limit the negative impact of route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] implementations. "Optimizing ACK mechanism for QUIC", Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang, 2021-05-25, 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. "Describing QUIC's Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2021-05-05, This document describes the core transport protocol data units used in the QUIC protocol using a machine-readable augmented packet header diagram format. It is intended as an example of the augmented packet header diagram language, and not as a contribution to the development of the QUIC protocol. "PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks", Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar, 2021-07-12, 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 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 networks in an efficient manner with simple OAM protocol extension which uses dataplane forwarding alone for sending echo reply. "BGP Classful Transport Planes", Kaliraj Vairavakkalai, Natrajan Venkataraman, Balaji Rajagopalan, Gyan Mishra, Mazen Khaddam, Xiaohu Xu, Rafal Szarecki, Deepak Gowda, 2021-08-25, This document specifies a mechanism, referred to as "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 co-operating administrative domains. These domains may be administetered by the same provider or closely co-ordinating provider networks. It makes it possible to advertise multiple tunnels to the same destination address, thus avoiding need of multiple loopbacks on the egress node. 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. It carries transport prefixes across tunnel domain boundaries (e.g. in Inter-AS Option-C networks), 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. "Use Identity as Raw Public Key in EAP-TLS", chenmeiling, Li Su, Haiguang Wang, 2021-05-16, This document specifies the use of identity as a raw public key in EAP-TLS both for TLS1.2 and TLS1.3, 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 protocol procedures of EAP-TLS-IBS 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, 2021-08-15, 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. "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2021-10-19, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. "Light Weighted EVPN", Yubao Wang, Ran Chen, 2021-08-30, SRv6 EVPN [I-D.ietf-bess-srv6-services] is not sufficient for some light-weighted use cases. When PBB EVPN [RFC7623] over SRv6 is used to support these light-weighted EVPN services, it is complicated to make use of the SID list to carry a function that is aiming for C-MACs. In [RFC8986], End.DX2 function is defined, this function can be used in EVPN VPLS. When it is used in EVPN VPLS, the data-plane learning defined in End.DT2U function can also be transplanted into End.DX2 function. On the basis of such extended End.DX2 function, SRv6 EVPN can be improved to meet all the requirements per [RFC7623] and bring us some other benefits. Such SRv6 EVPN is called light-weighted SRv6 EVPN, and it will be more simpler than PBB EVPN over SRv6. It is easy for the light-weighted SRv6 EVPN to carry a SID that is aiming for customer ethernet packets, because there will be no other ethernet header between the SID list and the customer ethernet header. These SIDs may be user-defined functions for the customer ethernet headers. "Generalized SRv6 Network Programming for SRv6 Compression", Weiqiang Cheng, Zhenbin Li, Cheng Li, Francois Clad, Liu Aihua, Chongfeng Xie, Yisong Liu, Shay Zadok, 2021-04-29, 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.filsfilscheng-spring-srv6-srh-comp-sl-enc] framework. "A Simple LISP NAT-Traversal Implementation", Dino Farinacci, 2021-05-11, This informational draft documents the lispers.net LISP NAT-Traversal implementation. "Secure Frame (SFrame)", Emad Omara, Justin Uberti, Alex Gouaillard, Sergio Murillo, 2021-09-17, This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from other approaches through its use of media frames as the encryptable unit, instead of individual RTP packets, which makes it more bandwidth efficient and also allows use with non-RTP transports. "Internet Protocol Encapsulation of AX.25 Frames", Iain Learmonth, 2021-05-23, This document describes a method for the encapsulation of AX.25 Link Access Protocol for Amateur Packet Radio frames within IPv4 and IPv6 packets. Obsoletes RFC1226. Note Comments are solicited and should be addressed to the author(s). The sources for this draft are at: https://github.com/irl/draft-rfc1226-bis "The GNU Name System", Martin Schanzenbach, Christian Grothoff, Bernd Fix, 2021-05-06, This document contains the GNU Name System (GNS) technical specification. "Advertising Segment Routing Policies Attributes in BGP", Liu Yao, Shaofu Peng, 2021-08-19, This document proposes extensions of BGP and defines some new Segment Types with algorithm information to meet more requirements when delivering SR Policy via BGP. "Use cases of Application-aware Networking (APN) in Game Acceleration", Shuai Zhang, Chang Cao, Shuping Peng, Zhenbin Li, 2021-06-07, With the development of the Internet, game industry has risen rapidly, from handheld game consoles to PC games and mobile games. The types of games are diversified, while the number of game users is increasing year by year. The game market is maturing quickly. Nowadays, the scale of game users is large and they belong to the easy-to-consume groups. Among all the games, those require frequent interactions and involve video streaming usually have highly demanding requirements on the network in terms of guaranteed network latency and reliability. Therefore, from the aspect of ensuring better gaming experience, it is desirable of differentiating the particular gaming application flows and providing high-priority network services for those demanding gamers. This document describes the game acceleration scenarios using Application-aware Networking (APN) technology. In these scenarios, APN can identify the specific requirements of particular gaming applications, steer the flows to the game processors close to the users, and provide SLA guaranteed network services such as low latency and high reliability. "Identity Module for TLS Version 1.3", Pascal Urien, 2021-07-25, 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 COSE Security Context", Brian Sipos, 2021-06-03, This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile of COSE and for PKIX certificates are also defined for BPSec interoperation. "Trusted Path Routing", Eric Voit, Chennakesava Gaddam, Guy Fedorkow, Henk Birkholz, 2021-09-07, 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. "Real-time Transport Object delivery over Unidirectional Transport (ROUTE)", Waqar Zia, Thomas Stockhammer, Lena Chaponniere, Giridhar Mandyam, 2021-06-23, The Real-time Transport Object delivery over Unidirectional Transport protocol (ROUTE protocol) is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers, for example, it can be a file, or a DASH or HLS segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications. The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over IP/UDP including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g. to provide security it can leverage IP security protocols such as IPSec. This document specifies the ROUTE protocol such that it could be used by a variety of applications for delivery of Application Objects by specifying their own profiles of this protocol (e.g. by adding or constraining some features). "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2021-05-17, 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. "SCHC over PPP", Pascal Thubert, 2021-04-21, This document extends RFC 5172 to signal the use of SCHC as the compression method between a pair of nodes over PPP. Combined with RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi. "Distributed Ledger Time-Stamp", Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano, 2021-06-08, 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. "DNS Access Denied Error Page", Tirumaleswar Reddy.K, Neil Cook, Dan Wing, Mohamed Boucadair, 2021-06-04, When a DNS server filters a query, the response to such query conveys no detailed explanation that elaborates why that query was blocked, leading thus to end-user confusion. A solution to this problem is needed in order to enhance the user experience. This document defines a method to return an URI that explains the reason why a DNS query was filtered by a DNS server. "Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)", Miroslav Milinovic, 2021-04-21, This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document obsoletes RFC 6338. "Transport Considerations for IP and UDP Proxying in MASQUE", Magnus Westerlund, Marcus Ihlar, Zaheduzzaman Sarker, Mirja Kuehlewind, 2021-07-12, The HTTP Connect method uses back-to-back TCP connections to and from a proxy. Such a solution takes care of many transport aspects as well as IP Flow related concerns. With UDP and IP proxying on the other hand, there are several per-packet and per-flow aspects that need consideration to preserve the properties of end- to-end IP/UDP flows. The aim of this document is to highlight and provide solutions for these issues related to UDP and IP proxying. "Digital Twin Network: Concepts and Reference Architecture", Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed Boucadair, Christian Jacquenet, 2021-07-07, 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 realize efficient and intelligent management and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network (DTN), provides the definition and reference architecture, application scenarios, and then describes the benefits and key challenges of such technology. "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, 2021-08-17, 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. "Private Line Emulation VPWS Signalling", Steven Gringeri, Jeremy Whittaker, Christian Schmutzer, Patrice Brissette, 2021-05-03, This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). "Stateless SRv6 Point-to-Multipoint Path", Huaimo Chen, Mike McBride, Yanhe Fan, Xuesong Geng, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu, 2021-07-11, 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. "Bitmask Route Target", Zhaohui Zhang, Srihari Sangli, Jeffrey Haas, 2021-04-21, This document specifies a new type of Route Target called Bitmask Route Target as a BGP Community Container. The key element of a Bitmask Route Target is a Bitmask. Two Bitmask Route Targets are considered equivalent for the purpose of controlling route propagation (via Route Target Constraints) and importation if the result of logical "AND" operation of the Bitmask of the two is non- zero. "Generic Route Constraint Distribution Mechanism for BGP", Zhaohui Zhang, Jeffrey Haas, 2021-04-21, This document defines a mechanism based upon Constrained Route Distribution for BGP (RFC 4684) that works with various types of BGP Community-like Path Attributes. Similar to RFC 4684, this mechanism can be used to build a route distribution graph to limit the propagation of BGP Routes. Unlike RFC 4684, this mechanism is not restricted to BGP Extended Communities (RFC 4360). "Principles for the Involvement of Intermediaries in Internet Protocols", Martin Thomson, 2021-07-06, 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, 2021-09-24, 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. "Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM) Data", Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro, 2021-07-11, In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information while the packet traverses a particular network domain. 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. "Traffic Steering using BGP Flowspec with SRv6 Policy", Jiang Wenying, Yisong Liu, Shuanglong Chen, 2021-07-11, BGP Flow Specification (FlowSpec) [RFC8955] 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 aslo attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SRv6 Policy. "Signal Degrade Indication in Segment Routing over MPLS Network", Liuyan Han, Fan Yang, Junfeng Zhao, 2021-08-15, 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, 2021-06-28, 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, Haomian Zheng, Aihua Guo, Xufeng Liu, 2021-07-12, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) with Traffic Engineering (MPLS-TE) networks. "Path Information Detection in Application-aware IPv6 Networking", Zongpeng Du, Peng Liu, 2021-06-24, This document introduces a method to detect path information in Application-aware IPv6 Networking. "SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2021-10-19, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS. "Trustworthiness Vectors for the Software Updates of Internet of Things (SUIT) Workflow Model", Henk Birkholz, Brendan Moran, 2021-07-12, The IETF Remote Attestation Procedures (RATS) architecture defines Conceptual Messages as input and output of the appraisal process that assesses the trustworthiness of remote peers: Evidence and Attestation Results. Based on the Trustworthiness Vectors defined in Trusted Path Routing, this document defines a core set of Claims to be used in Evidence and Attestation Results for the Software Update for the Internet of Things (SUIT) Workflow Model. Consecutively, this document is in support of the Trusted Execution Environment Provisioning (TEEP) architecture, which defines the assessment of remote peers via RATS and uses SUIT for evidence generation as well as a remediation measure to improve trustworthiness of given remote peers. "Cacheable OSCORE", Christian Amsuess, Marco Tiloca, 2021-07-12, 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. "Client Hint Reliability", David Benjamin, 2021-06-01, This document defines the Critical-CH HTTP response header, and the ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably specify their Client Hint preferences, with minimal performance overhead. 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/davidben/http-client-hint-reliability. "BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities", Yali Wang, Shunwan Zhuang, Yunan Gu, Ran Pang, 2021-07-12, This document defines extensions to 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. "AS Hijack Detection and Mitigation", Kotikalapudi Sriram, Doug Montgomery, 2021-07-11, 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, 2021-06-15, 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. "Compact UUIDs for Constrained Grammars", Dorian Taylor, 2021-08-20, The Universally Unique Identifier is a suitable standard for, as the name suggests, uniquely identifying entities in a symbol space large enough that the identifiers do not collide. Many formal grammars, however, are too restrictive to permit the use of UUIDs in their canonical representation (described in RFC 4122 and elsewhere), despite it being useful to do so. This document specifies an alternative compact representation for UUIDs that preserves some properties of the canonical form, with three encoding varietals, to fit these more restrictive contexts. "Extensions to enable wireless reliability and availability in multi- access edge deployments", Carlos Bernardos, Alain Mourad, 2021-07-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 describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. "P2MP Policy Ping", Hooman Bidgoli, Dan Voyer, Rishabh Parekh, Zhaohui Zhang, 2021-09-27, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs). "IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions", Venkata Munukutla, Shivam Vaid, Aditya Mahale, Devang Patel, 2021-08-08, This draft proposes couple of new Forwarding exceptions related Information Elements (IEs) and Templates for the IP Flow Information Export (IPFIX) protocol. These new Information Elements and Exception Template can be used to export information about any forwarding errors in a network. This essential information is adequate to correlate packet drops to any control plane entity and map it to an impacted service. Once exceptions are correlated to a particular entity, an action can be assigned to mitigate such problems essentially enabling self-driving networks. "SVG Tiny Portable/Secure", Alex Brotman, J. Adams, 2021-10-11, 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. "Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)", Nicholas Gajcowski, Michael Jenkins, 2021-10-21, The United States Government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Michael Richardson, 2021-06-21, 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 "Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT", Hang Yuan, Tianran Zhou, Weidong Li, Giuseppe Fioccola, Yali Wang, 2021-07-09, This document defines PCEP extensions to distribute In-situ Flow Information Telemetry (IFIT) information. So that IFIT behavior can be enabled automatically when the path is instantiated. 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. The IFIT attributes here described can be generalized for all path types but the application to Segment Routing (SR) is considered in this document. This document extends PCEP to carry the IFIT attributes under the stateful PCE model. "Usage scenarios of Application-aware Networking (APN) for SD-WAN", Feng Yang, Weiqiang Cheng, Shuping Peng, Zhenbin Li, 2021-10-20, 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, 2021-09-24, 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. "EVPN VPWS as VRF Attachment Circuit", Yubao Wang, Zheng Zhang, 2021-08-28, When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC and its IP-VRF instance. From the viewpoint of the IP-VRF instance, a local virtual interface takes the place of that remote "VRF-AC". The IP address for that VRF-AC is now configured to the virtual interface, in other words, the virtual interface is the actual VRF-AC of the IP-VRF instance. The virtual interface is also the AC of that VPWS instance, in other words, the virtual interface is cross- connected to that remote "VRF-AC" by the VPWS instance. This document proposes an extension to [I-D.ietf-bess-evpn-inter-subnet-forwarding] to support this scenario. "Soure Address Validation: Gap Analysis", Dan Li, Jianping Wu, Yunan Gu, Lancheng Qin, Tao Lin, 2021-07-04, This document identifies scenarios where existing IP spoofing approaches for detection and mitigation don't perform perfectly. Exsiting SAV (source address validation) approaches, either Ingress ACL filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], Feasible Path uRPF [RFC 3704], or Enhanced Feasible-Path uRPF [RFC8704] has limitations regarding eihter automated implemetation objective or detection accuracy objective (0% false positive and 0% false negative). This document provides the gap analysis of the exsting SAV approaches, and also provides solution discussions. "The VERBATIM Digest Algorithm for DS records", Peter van Dijk, 2021-08-10, The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER", Ran Chen, BenChong Xu, 2021-06-23, This draft specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for BIER. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE", Ran Chen, BenChong Xu, 2021-06-23, This document specifies extensions to PCEP protocol when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a BIER-TE network and telling the edge routers what instructions to attach to packets as they enter the network. "YANG data model for BGP Segment Routing Extensions", krishnadeevi, Syed Raza, Jaganbabu Rajamanickam, Kausik Majumdar, Bruno Decraene, Haibo Wang, 2021-07-12, This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP. "YANG data model for BGP Segment Routing TE Extensions", krishnadeevi, Syed Raza, Jaganbabu Rajamanickam, Kausik Majumdar, Bruno Decraene, Zhichun Jiang, Xuesong Geng, 2021-07-12, This document defines a YANG data model that can be used to configure and manage Segment Routing TE extensions in BGP. "APN Security and Privacy Considerations", Shuping Peng, Zhenbin Li, Dan Voyer, Cong Li, Peng Liu, Chang Cao, 2021-06-16, Application-aware Networking (APN) aims to convey Application-aware Information (APN attribute) including APN ID and APN parameters indicating application group-level and user group-level requirements along with the data packets into the network and enable the network to provide corresponding fine-granular network services. There have been challenges of the privacy and security issues that could potentially be introduced by conveying the APN attribute into the network. This document describes the security and privacy considerations of APN in various possible scenarios wherein APN will be deployed. "An Interoperability Architecture for Blockchain/DLT Gateways", Thomas Hardjono, Martin Hargreaves, Ned Smith, 2021-04-20, With the increasing interest in the potential use of blockchain systems for virtual assets, there is a need for these assets to have mobility across blockchain systems. An interoperability architecture for blockchain systems is needed in order to permit the secure flow of virtual assets between blockchain systems, satisfying the properties of transfer atomicity, consistency and durability. The architecture must recognize that there are different blockchain systems, and that the interior constructs in these blockchains maybe incompatible with one another. Gateway nodes perform the transfer of virtual assets between blockchain systems while masking the complexity of the interior constructs of the blockchain that they represent. "Open Digital Asset Protocol", Martin Hargreaves, Thomas Hardjono, Rafael Belchior, 2021-05-08, This memo describes the Open Digital Asset Protocol (ODAP). ODAP is an asset transfer protocol that operates between two gateway devices. The protocol includes a description of virtual or digital assets held on distributed ledgers in an open and interoperable format, a session negotiation part and message passing flows between gateways connecting disparate distributed ledger technologies (DLTs). "The 'haptics' Top-level Media Type", Yeshwant Muthusamy, Chris Ullrich, 2021-05-17, 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. "Federated TLS Authentication", Jakob Schlyter, =?utf-8?q?Stefan_Hal=C3=A9n?=, 2021-10-12, 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, 2021-10-04, This document describes the Multicast Synchronisation (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 Path Protection", Liu Yao, Shaofu Peng, 2021-05-19, This document proposes extensions of BGP to provide 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, 2021-10-11, 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 at Edge Networks", Haoyu Song, 2021-10-11, To mitigate the IPv6 header overhead in edge networks, this draft proposes to use short hierarchical 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. 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 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. "System Configuration Data Handling Behavior", Chong Feng, Qiufang Ma, Chongfeng Xie, 2021-06-22, This document defines an optional "system" datastore to allow clients populate the system configuration into running datastore in the device. It also defines a capability-based extension to the NETCONF protocol that helps the NETCONF client identify how system configuration are processed by the server. "QUIC Multipath Negotiation Option", Christian Huitema, 2021-09-12, The initial version of QUIC provides support for path migration. We propose a simple mechanism to support not just migration, but also simultaneous usage of multiple paths. In its simplest form, this mechanisms simply requires that multipath senders keep track of which packet is sent on what path, and use that information to manage congestion control and loss recovery. With that, clients can send data on any validated path, and server on any validated path on which the client recently sent non-probing packets. A more sophisticated mechanism can be negotiated to explicitly manage paths and packet scheduling. "Signature Validation Token", Stefan Santesson, Russ Housley, 2021-09-03, Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. SVT supports electronic signatures in CMS, XML, and PDF documents. "PDF Signature Validation Token", Stefan Santesson, Russ Housley, 2021-09-03, This document defines a PDF profile for the Signature Validation Token defined in [SVT]. "XML Signature Validation Token", Stefan Santesson, Russ Housley, 2021-09-03, This document defines a XML profile for the Signature Validation Token defined in [SVT]. "Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang, Yisong Liu, Ying Cheng, 2021-07-08, This document discusses the redundant ingress router failover in multicast domain. "User Devices Explicit Monitoring", Mauro Cociglio, Massimo Nilo, Fabio Bulgarella, Giuseppe Fioccola, 2021-07-12, 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, 2021-10-21, 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, 2021-04-30, 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, 2021-09-26, 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, 2021-07-12, 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, 2021-07-12, 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/Traceroute for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes", Xiao Min, Shaofu Peng, 2021-05-17, 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. "BGP SR Policy Extensions for Virtual Transport Network", Jie Dong, Zhibo Hu, Ran Pang, 2021-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. In scenarios where multiple Virtual Transport Networks (VTNs) exist in the network, the VTN in which the SR policy is instantiated may also need to be specified, so that the header of the packet can also be augmented with the information associated with the VTN. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines extensions to BGP SR policy to specify the VTN associated with the SR policy. "Beyond 64KB Limit of IKEv2 Payloads", C. Tjhai, Tobias Heider, Valery Smyslov, 2021-07-09, 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. "Realizing Network Slices in IP/MPLS Networks", Tarek Saad, Vishnu Beeram, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, 2021-07-11, Network slicing provides the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Network slices need to operate in parallel while providing slice elasticity in terms of network resource allocation. The Differentiated Service (Diffserv) model allows for carrying multiple services on top of a single physical network by relying on compliant nodes to apply specific forwarding treatment (scheduling and drop policy) on to packets that carry the respective Diffserv code point. This document proposes a solution based on the Diffserv model to realize network slicing in IP/MPLS networks. "Extension of Transport Aware Mobility in Data Network", Kausik Majumdar, Uma Chunduri, Linda Dunbar, 2021-07-12, The existing Transport Network Aware Mobility for 5G [TN-AWARE- MOBILITY] draft specifies a framework for mapping the 5G mobile systems Slice and Service Types (SSTs) to corresponding underlying network paths in IP and Layer 2 Transport networks.The focus of that work is limited to the mobility domain and transport network characteristics till the UPF and doesn't go beyond the UPF to the Data Network. To maintain E2E transport network characteristics the framework needs to be extended beyond UPF. This document describes a framework for extending the mobility aware transport network characteristics from the UPF through the Data Network. "BGP App Metadata for 5G Edge Computing Service", Linda Dunbar, Kausik Majumdar, Haibo Wang, 2021-09-23, This draft describes a new AppMetaData subTLV carried by Tunnel Encap[RFC9012] Path Attribute for egress router to advertise the running status and environment of the directly attached 5G Edge Computing servers. The AppMetaData can be used by the ingress routers in the 5G Local Data Network to make intelligent path selection for flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services. The extension enables a feature, called soft anchoring, which makes one Edge Computing Server at one specific location to be more preferred than others for the same application to receive packets from a specific source (UE). "MAC address randomization", Juan Zuniga, Carlos Bernardos, Amelia Andersdotter, 2021-07-12, 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 futures standardization activities. "A Simplified Scalable ELAN Service Model with Segment Routing Underlay", Sami Boutros, Siva Sivabalan, Himanshu Shah, Jim Uttaro, Dan Voyer, Bin Wen, Luay Jalil, 2021-10-11, This document proposes a new approach for deploying Ethernet LAN (ELAN) services with an objective of achieving high scalability, faster network convergence, and reduced operational complexity. Furthermore, it naturally brings the benefits of All-Active multihoming as well as MAC learning in data-plane. "Provisioning Initial Device Identifiers into Home Routers", Michael Richardson, 2021-05-21, This document describes a method to provisioning an 802.1AR-style certificate into a router intended for use in the home. The proceedure results in a certificate which can be validated with a public trust anchor ("WebPKI"), using a name rather than an IP address. This method is focused on home routers, but can in some cases be used by other classes of IoT devices. (RFCEDITOR please remove: this document can be found at https://github.com/mcr/homerouter-provisioning) "Separation of Data Path and Data Flow Sublayers in the Transport Layer", Hirochika Asai, 2021-09-15, 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", Danyang Chen, Hongwei Yang, Kehan Yao, Giuseppe Fioccola, 2021-07-08, As an important technical means to detect network state, network measurement has attracted more and more attention in the development of network. 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, namely the process of realizing user or network operator to allocate network states as needed. And it can be as a specified user case of intent based network. "DC aware TE topology model", Young Lee, Xufeng Liu, Luis Contreras, 2021-07-12, This document proposes the extension of the TE topology model for including information related to data center resource capabilities. "Research on multipriority scheduling technology for real-time interconnection between industrial field data and cloud information", Chaowei Tang, Ruan Shuai, Huang Baojin, Wen Haotian, Feng Xinxin, 2021-05-21, This document describes the multipriority scheduling technology for the interconnection between industrial field and cloud data in the application of 5G communication. The technology includes spectrum resource scheduling based on 5G slice in the process of accessing industrial data and task collaborative scheduling based on edge computing. "Architecture Based on IPv6 and 5G for IIoT", Chaowei Tang, Wen Haotian, Ruan Shuai, Baojin Huang, Feng Xinxin, 2021-06-08, As the foundation of the current new round of industrial revolution, the Industrial Internet of Things (IIoT) based on cyber-physical systems (CPS) [smart-factory] has become the focus of research in various countries. One of the key issues in the entire development stage of IIoT is the standardization of the IIoT architecture. With the development of intelligent manufacturing technology, the number of IIoT devices is expected to increase sharply, and large amounts of data will be generated in the industrial manufacturing process. However, traditional industrial networks cannot meet the IIoT requirements for high data rates, low latency, massive connections, interconnection, and interoperability. Current IIoT architectures also have various limitations, including those in mobility, security, scalability, and communication reliability. These limitations hinder the development and implementation of IIoT. As a network layer protocol, IPv6 can solve the problem of IPv4 address exhaustion. Meanwhile, as a high-speed, low-latency, wireless communication technology, 5G has great potential in promoting IIoT. To solve the aforementioned problems, this draft proposes an IIoT architecture based on IPv6 and 5G. The architecture can provide high-speed, low- latency communication services and possesses massive connectivity, mobility, scalability, security, and other features for industrial devices. It can also provide generalized, refined, flexible network services for devices outside factories. Moreover, an information model is defined to standardize the representation of information in IIoT. The security challenges in and recommendations for IIoT are also discussed. "Explicit Flow Measurements Techniques", Mauro Cociglio, Alexandre Ferrieux, Giuseppe Fioccola, Igor Lubashev, Fabio Bulgarella, Isabelle Hamchaoui, Massimo Nilo, Riccardo Sisto, Dmitri Tikhonov, 2021-07-12, 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. "Privacy Pass: Centralization Problem Statement", Mark McFadden, 2021-05-04, This document discusses the problems associated with strict upper bounds on the number of Privacy Pass servers in the proposed Privacy Pass ecosystem. It documents a proposed problem statement. "Protocol and Engineering Effects of Consolidation", Dominique Lazanski, Mark McFadden, Eliot Lear, 2021-07-12, This document contributes to the ongoing discussion surrounding Internet consolidation. Though there has been much interest in the topic, the conversation has waned. This document aims to discuss recent areas of Internet consolidation that are technical, economic and engineering focused and provide some suggestions for advancing the discussion. "A Simplified Scalable E-Line Service Model with Segment Routing Underlay", Sami Boutros, Siva Sivabalan, Jim Uttaro, Dan Voyer, Bin Wen, Luay Jalil, 2021-10-11, This document proposes a new approach for realizing Ethernet line (E-Line) services over Segment Routing (SR) networks. This approach significantly improves scalability and convergence of control plane, and simplifies network operation. Furthermore, it naturally yields All-Active multi-homing support for E-Line services without relying on any overlay techniques. "BIER Egress Protection", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Boris Khasanov, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-08-26, This document describes a mechanism for fast protection against the failure of an egress node of a "Bit Index Explicit Replication" (BIER) domain. It does not have any per-flow state in the core of the domain. For a multicast packet to an egress node of the domain, 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. "BIER Fast ReRoute", Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-07-02, 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 Extensions 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. The BIER-FRR extensions are applied locally at the point of local repair (PLR) and do 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. "A Simplified Scalable L3VPN Service Model with Segment Routing Underlay", Sami Boutros, Siva Sivabalan, Jim Uttaro, Dan Voyer, Bin Wen, Luay Jalil, 2021-10-11, This document proposes a new approach for realizing classical L3VPN (vpnv4/vpnv6/6PE/6VPE) over Segment Routing (SR) networks. It significantly improves scalability and convergence of the L3VPN control plane. Furthermore, it naturally brings the benefits of All- Active multi-homing support to the classical L3VPN. "YANG Data Model for SR Service Programming", Jaganbabu Rajamanickam, Syed Raza, Daniel Bernier, Gaurav Dawra, Cheng Li, 2021-07-12, This document describes a YANG data model for Segment Routing (SR) Service Programming. The model serves as a base framework for configuring and managing an SR based service programming. Additionally, this document specifies the model for a Service Proxy for SR-unaware services. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "Framework and Data Model for OTN Network Slicing", Haomian Zheng, Italo Busi, Aihua Guo, Luis Contreras, Oscar de Dios, Victor Lopez, Sergio Belotti, Dieter Beller, Reza Rokui, Yunbin Xu, Yang Zhao, 2021-07-12, 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. "Describing TCP with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2021-05-05, This document describes TCP, and a number of its extensions, using Augmented Packet Header Diagrams. This document is an example of the Augmented Packet Header Diagram language: it is not intended as a contribution to any ongoing or future work on maintaining or extending TCP. "Describing UDP with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2021-05-05, This document describes UDP using Augmented Packet Header Diagrams. This document is an example of the Augmented Packet Header Diagram language: it is not intended as a contribution to any ongoing or future work on maintaining or extending UDP. "An Extension of I2NSF Framework for Security Management Automation in Cloud-Based Security Services", Jaehoon Jeong, Patrick Lingga, J., PARK, 2021-08-21, This document describes an extension of the framework of Interface to Network Security Functions (I2NSF) for Security Management Automation (SMA) in cloud-based security services. The security management automation in this document deals with a security polity translation and a feedback-based security service enforcement. To support these two features in SMA, this document specifies an augmented architecture of the I2NSF framework with a new system component and a new interface. "Mailing List Manager (MLM) Transformations", Alessandro Vesely, 2021-05-10, 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 describes cases where it is possible to revert MLM transformations and hence verify DomainKeys Identified Mail (DKIM) signatures that were applied at submission time. For reliable results, some compliance is required of all agents involved, author domain signers, MLMs, forwarders, and final recipients. MLM transformation reversion reduces the DMARC's effects on indirect mail flows. "Identity Header Error Handling", Chris Wendt, 2021-07-12, This document extends STIR and the Authenticated Identity Management in the Session Initiation Protocol (SIP) related to error handling for STIR verification services and how they feedback errors to STIR authentication services. Specifically, the use of a Reason header field and addressing scenarios that use multiple identity headers where some may have errors and others may not and the handling of those situations is defined. "RADIUS Extension for Certificate-based SSH Authentication", Devendra Vishwakarma, Prakash suthar, Vivek Agarwal, Anil Jangam, 2021-06-04, A scalable and centralized mechanism is required for a certificate- based administrative access to multitude of virtualized and physical network functions. While there are mechanisms that exist today to provide secure administrative command-line and API-based access, there are certain management and maintenance overheads as well as certain scalability challenges related to it. In this draft we discuss these challenges and propose a standardized, centralized server-based mechanism to authenticate a user over an SSH session using its client certificate. "Key Exchange Without Forward Secrecy is NOT RECOMMENDED", John Mattsson, 2021-05-18, Key exchange without forward secrecy enables passive monitoring. Massive pervasive monitoring attacks relying on key exchange without forward secrecy has been reported, and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to the long-term authentication keys enables a passive attacker to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. psk_ke does not provide forward secrecy and is NOT RECOMMENDED. This document sets the IANA registration of psk_ke to NOT RECOMMENDED. "JWS Clear Text JSON Signature Option (JWS/CT)", Bret Jordan, Samuel Erdtman, Anders Rundgren, 2021-10-12, This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT. 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 (also known as "Clear Text" signing). 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. "NTPv5 use cases and requirements", James Gruessing, 2021-10-10, This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supersede version 4 of the NTP protocol [RFC5905] presently referred to as NTP version 5 ("NTPv5"). This document is non-exhaustive and does not in its current version represent working group consensus. "Network Time Protocol Version 5", Miroslav Lichvar, 2021-10-18, This document describes the version 5 of the Network Time Protocol (NTP). "Trusted Resolution System and Protocol Extension", Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2021-05-23, 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, 2021-05-23, 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, 2021-05-31, This draft describes a lightweight in-band edge-to-edge network round trip time measurement architecture and suggests implementations. 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. "IPv6 Hop-by-Hop Options Processing Procedures", Robert Hinden, Gorry Fairhurst, 2021-06-02, 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. "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", Pascal Thubert, Tim Winter, 2021-05-31, Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. "SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li, 2021-05-27, 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. "Multipath Extension for QUIC", Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, Zhenyu Li, 2021-09-05, This document specifies multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. The extension is compliant with the single-path QUIC design. The design principle is to support multipath by adding limited extension to [QUIC-TRANSPORT]. "SDP Superimposition Grouping framework", Rohit Abhishek, Stephan Wenger, 2021-06-01, This document defines semantics that allow for signaling a new SDP group "supim" for superimposed media in an SDP session. The "supim" attribute can be used by the application to relate all the fully or partly superimposed visual media streams enabling them to be added as an overlay on top of any one or more background visual media streams. The superimposition grouping semantics is helpful if the media stream data is separate and transported via different sessions. "http2 window size use case", chenmeiling, Li Su, 2021-06-14, This document presents an use case which actually happening in our network, 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. "http2 window size setting", chenmeiling, Li Su, 2021-06-14, This document proposed the minimum value setting mechanism for HTTP2.0 Window and Window_update, and a Window_update frame sending mechanism. "APN Scope and Gap Analysis", Shuping Peng, Zhenbin Li, Gyan Mishra, 2021-05-24, The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an attribute to allow for the implementation of fine-grain user group-level and application group- level requirements at 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 realize this composite network service provisioning along the path very efficiently. This document further clarifies the scope of the APN work and describes the solution gap analysis. "SRv6 In-situ Active Measurement", Haoyu Song, Tian Pan, 2021-06-14, This draft describes a data-plane in-band active measurement method for SRv6. A packet containing an SRH uses a flag bit to indicate it is a probing packet. The IOAM header and data are encapsulated in UDP payload. The probing packet originates from a segment source node and terminates at a configured segment endpoint node. Each segment node on the path, when detecting the flag, parses the UDP header and the IOAM header, and adds data to the IOAM node data fields. The method avoids the performance and encapsulation issues for applying IOAM in SRv6 networks. Multiple applications can be supported by the method. "Using Entropy Label for Network Slice Identification in MPLS networks.", Bruno Decraene, Clarence Filsfils, Wim Henderickx, Tarek Saad, Vishnu Beeram, Luay Jalil, 2021-08-06, This document 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. This document also extends 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. "Scalable Network Slicing over SR Networks", Tarek Saad, Vishnu Beeram, Ran Chen, Shaofu Peng, Bin Wen, Daniele Ceccarelli, 2021-09-16, Multiple network slices can be realized on top of a single shared network. A router that requires forwarding of a packet that belongs to a slice aggregate may have to decide on the forwarding action to take based on selected next-hop(s), and the forwarding treatment (e.g., scheduling and drop policy) to enforce based on the slice aggregate per-hop behavior. Segment Routing is a technology that enables the steering of packets in a network by encoding pre- established segments within the network into the packet header. This document introduces mechanisms to enable forwarding of packets over a specific slice aggregate along a Segment Routing (SR) path. "On loading MUD URLs from QR codes", Michael Richardson, Jacques Latour, Hassan Gharakheili, 2021-05-15, This informational document details a protocol to load MUD definitions for devices which have no integrated MUD (RFC8520) support. This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest. RFCEDITOR please remove: Pull requests and edit welcome at: "PCAP Capture File Format", Guy Harris, Michael Richardson, 2021-06-23, This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. "CDNI Request Routing Extensions", Nir Sopher, Sanjay Mishra, 2021-07-28, 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 Metadata Footprint Types defined in RFC 8006. The Footprint Types defined in this document can be used for Footprint objects as part of the Footprint & Capabilities Advertisement interface (FCI) defined in RFC 8008. The defined Footprint Types are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. "Photonic firewall oriented routing and spectrum allocation strategy in optical networks", Li Xin, Lu Zhang, Ying Tang, Zicheng Shi, Shanguo Huang, 2021-06-28, 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. "Architecture and application scenario for fused service function chain", Jinyou Dai, Xueshun Wang, Jun Gao, 2021-06-27, 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 and control plane. Fused service function chain is a expansion for 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. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, Chuck Lever, 2021-07-06, 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 is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. The content of this document reflects that of RFC8881, presented in the form of an I-D. This is intended to provide a helpful point of comparision for drafts leading to an eventual rfc5661bis document suite. This document can serve as a baseline to enable use of rfcdiff when reviewing such drafts. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, 2021-08-13, 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 will give rise to a suite 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. "Lightweight Directory Access Protocol (LDAP) Procedures and Schema Definitions for the Storage of X.660 Registration Information", Jesse Coretta, 2021-07-25, This specification defines models, procedures and schema definitions meant to facilitate the storage of [X.660] registration data within a Lightweight Directory Access Protocol Directory Information Tree. "Truncated SID Inter Domain Considerations", Liu Yao, Shaofu Peng, Greg Mirsky, 2021-07-25, This document introduces a method for interworking between domains of Segment Routing in IPv6 network that use different levels of Segment Identifier's compression. "SR-MPLS / SRv6 Transport Interworking", Shraddha Hegde, Parag Kaneriya, Ron Bonica, Shaofu Peng, Greg Mirsky, Zheng Zhang, Bruno Decraene, 2021-07-12, 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", Italo Busi, Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Oscar de Dios, 2021-07-12, This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". "DLT Gateway Crash Recovery Mechanism", Rafael Belchior, Miguel Correia, Thomas Hardjono, 2021-10-11, This memo describes the crash recovery mechanism for the Open Digital Asset Protocol (ODAP), called ODAP-2PC. The goal is to assure gateways running ODAP to be able to recover from crashes, and thus preserve the consistency of an asset across ledgers (i.e., double spend does not occur). This draft includes the description of the messaging and logging flow necessary for the correct functioning of ODAP-2PC. "Generic Delivery Functions", Zhaohui Zhang, Ron Bonica, Kireeti Kompella, Greg Mirsky, 2021-08-25, 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. "Path Computation Element Protocol(PCEP) Extension for RSVP Color", Balaji Rajagopalan, Vishnu Beeram, Gyan Mishra, 2021-07-12, This document specifies extensions to Path Computation Element Protocol (PCEP) to carry a newly defined attribute of RSVP LSP called 'color' that can be used as a guiding criterion for selecting the LSP as a next hop for a service route. "Segment Routing Header encapsulation for Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, 2021-07-09, 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, Xinjun Chen, 2021-08-02, 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. "Byzantine Fault Tolerant Set Reconciliation", Elias Summermatter, Christian Grothoff, 2021-06-16, This document contains a protocol specification for Byzantine fault- tolerant Set Reconciliation. "Oblivious HTTP", Martin Thomson, Christopher Wood, 2021-08-24, This document describes a system for the forwarding of encrypted HTTP messages. This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client. "Binary Representation of HTTP Messages", Martin Thomson, Christopher Wood, 2021-08-10, This document defines a binary format for representing HTTP messages. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list (http@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/http/. Source for this draft and an issue tracker can be found at https://github.com/unicorn-wg/oblivious-http. "Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses", Roger Price, 2021-07-06, This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices, and in IT installations subject to an erratic public power supply. The UPS units typically interface to an Attachment Daemon in the system they protect. This daemon is in turn polled by a Management Daemon which notifies users and system administrators of power supply incidents, and takes system shutdown decisions. The commands and responses described by this document are exchanged between the UPS Attachment Daemon and the Management Daemon. Current practice leads to weak security and this is addressed in the Security Considerations sections of this document. "DLEP Radio Channel Utilization Extension", Henning Rogge, 2021-08-10, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. "BGP Extensions of SR Policy for Composite Candidate Path", Hao Li, Mengxiao Chen, Changwang Lin, 2021-08-02, 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, 2021-08-02, 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. "Delivered-To Email Header Field", Dave Crocker, 2021-08-27, The address to which email is delivered might be different than any of the addresses shown in any of the content header fields, created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command. Before final delivery, handling can entail a sequence of submission/delivery events, using different destination addresses that lead to the recipient. Also, a receiving system's delivery process can produce local address transformations. It can be helpful for a message to have a common way to record each delivery in such a sequence, and to include each address used for that recipient, such as for analyzing the path a message has taken, for loop detection, or for formulating the author's address in a reply message. This document defines a header field for this information. Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise possible privacy concerns. A header field such as this is not automatically assured of widespread use. Therefore this is being published as an Experiment, looking for constituency and for operational utility. The document is produced through the Independent RFC stream and was not subject to the IETF's approval process. "Updates to SID Verification for SR-MPLS in RFC 8664", Ran Chen, Samuel Sidor, Chun Zhu, Alexej Tokar, Mike Koldychev, 2021-07-12, This document updates [RFC8664] to clarify usage of "SID verification" bit signalled in Path Computation Element Protocol (PCEP), and this document proposes to define a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. "BGP Color-Aware Routing Problem Statement", Dhananjaya Rao, Swadesh Agrawal, Clarence Filsfils, Ketan Talaulikar, Bruno Decraene, Dirk Steinberg, Luay Jalil, Jim Guichard, Keyur Patel, Wim Henderickx, 2021-05-23, This document explores the scope, use-cases and requirements for a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider network environment. "Cookie Extension Limiting Its Availability to User Agent Components", Rafal Pietrak, 2021-08-18, This memo addresses cookies security by introduction of an additional constraints, web application designer may impose on cookie availability for localhost applications components. Here proposed new cookie attribute attempts to provide that missing functionality while retaining all currently known use scenarios of cookies. However, this new attribute is designed to be more useful for banking applications, then for social media networks. "A YANG Model for MPLS MSD", Yingzhen Qu, Acee Lindem, Stephane Litkowski, Jeff Tantsura, 2021-08-02, 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. "One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG", Zhenqiang Li, Mach Chen, Greg Mirsky, 2021-08-11, 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 a performance metric-based traffic steering policy across the member links. "Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics", Daniel King, Adrian Farrel, 2021-06-14, 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 were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers. Many proposals have been made to add semantics to IP addresses. The intent is usually to facilitate routing decisions based solely on the address and without the need to find and process information carried in other fields within the packets. This document describes the challenges to the existing routing system that are introduced by the addition of semantics to IP addresses. It then summarizes the opportunities for research into new or modified routing protocols to make use of new address semantics. This document is presented as 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. "Token Mediating and session Information Backend For Frontend", Vittorio Bertocci, Brian Campbell, 2021-04-25, This document describes how a JavaScript frontend can delegate access token acquisition to a backend component. In so doing, the frontend can access resource servers directly without taking on the burden of communicating with the authorization server, persisting tokens, and performing complex operations within the user agent that would require configuration, error management and reliance on authorization server capabilities (such as refresh token rotation) that aren't widely available today. "Simple Two-Way Direct Loss Measurement Procedure", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Stefano Salsano, 2021-08-09, 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. "Evolution of Endpoint Security - An Operational Perspective", Mark McFadden, 2021-08-16, This draft discusses the traditional model of security where endpoints in the network are protected by a variety of tools. It proposes a model for endpoints and then argues that the older, traditional approach is no longer sufficient for operational security at the endpoint. A series of operational examples are discussed in an Appendix. "Evolution of Endpoint Security - A Taxonomy for Endpoints", Mark McFadden, 2021-08-16, A separate document [I-D:draft-mcfadden-opsec-endp-evolve] attempts to establish the capabilities and limitations of endpoint-only security solutions and explore potential alternative approaches. That document discusses endpoints in general terms. It has been suggested that there are classes of endpoints that have different characteristics. Those classes may have completely different threat landscapes and the endpoints may have completely different security capabilities. As a companion to the endpoint evolution draft, this document provides a taxonomy of endpoints that is intended to provide a foundation for further work on endpoint security evolution and research on approaches to providing endpoint security alternatives in a diverse group of settings. "An Offset Extension Frame For HTTP/3 Data", Sam Hurst, 2021-08-13, 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. "DNSSEC automation", Ulrich Wisser, Shumon Huque, 2021-07-10, This document describes an algorithm and a protocol to automate DNSSEC Multi-Signer [RFC8901] "Multi-Signer DNSSEC Models" setup, operations and decomissioning. Using Model 2 of the Multi-Signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), [RFC8078] "Managing DS Records from the Parent via CDS/CDNSKEY" and [RFC7477] "Child-to-Parent Synchronization in DNS" to accomplish this. "Key Update for OSCORE", Rikard Hoeglund, Marco Tiloca, 2021-07-12, 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. This document defines how two OSCORE peers must follow these limits and what steps they must take to preserve the security of their communications. Therefore, this document updates RFC8613. Furthermore, this document specifies a lightweight method that two peers can use to update their keying material and establish a new OSCORE Security Context. "Split-Horizon DNS Configuration", Tirumaleswar Reddy.K, Dan Wing, Kevin Smith, 2021-09-15, When split-horizon DNS is deployed by a network, certain domains are only resolvable by querying the network-designated DNS server rather than a public DNS server. DNS clients which use DNS servers not provided by the network need to route those DNS domain queries to the network-designated DNS server. This document informs DNS clients of split-horizon DNS, their DNS domains, and is compatible with encrypted DNS. "PIM Join/ Prune Attributes for LISP Environments using Underlay Multicast", Vengada Govindan, Stig Venaas, 2021-06-04, This document specifies an extension to PIM Receiver RLOC Join/ Prune attribute that supports the construction of multicast distribution trees where the root and receivers are located in different Locator/ ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root ITR (Ingress Tunnel Router). "PCE for BIER-TE Path", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-10-17, 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, 2021-08-23, 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. "Date and Time on the Internet: Timestamps", Ujjwal Sharma, 2021-06-08, This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the proleptic Gregorian calendar. "BIER-TE Egress Protection", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-08-25, 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. "Intentionally Temporarily Degraded or Insecure", Wes Hardaker, 2021-10-21, Performing DNSKEY algorithm transitions with DNSSEC signing is unfortunately challenging to get right in practice without decent tooling support. This document weighs the correct, completely secure way of rolling keys against an alternate, significantly simplified, method that takes a zone through an insecure state. "Native Short Addresses for the Internet Edge", Guangpeng Li, Sheng Jiang, Donald Eastlake, 2021-05-25, This document describes a new approach to IP header compression including native short addresses adoption for use in scenarios where minimizing packet size is crucial but routing performance must be maximised. "Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth Using IGP and BGP-LS", Xiao Min, Zheng Zhang, Weiqiang Cheng, 2021-08-18, 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. "Terminal-based joint selection and configuration of MEC host and RAW network", Carlos Bernardos, Alain Mourad, 2021-09-09, 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. "One-way Delay Measurement Based on Reference Delay", Yang Li, Tao Sun, Hongwei Yang, Danyang Chen, Yali Wang, 2021-07-25, 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. "IETF Network Slice use cases", Weiqiang Cheng, Jiang Wenying, Ran Chen, Liyan Gong, Shaofu Peng, 2021-08-24, This draft supplements the usecase described in [I-D.ietf-teas-ietf-network-slice-definition] from the perspective of the operator.In specific,it mainly includes two types of the network slice customers from the perspective of operators: o End-to-end slicing cloud-network collaboration o The branch departments that use slices within the operator. "Analysis of VPN Routes Control in Shared BGP Session", Aijun Wang, Wei Wang, Gyan Mishra, Haibo Wang, Shunwan Zhuang, Jie Dong, 2021-09-06, This draft analyzes some scenarios and the necessaries for VPN routes control in the shared BGP session, which can be the used as the base for the design of related solutions. "Challenging Scenarios and Problems in Internet Addressing", Yihao Jia, Dirk Trossen, Luigi Iannone, Nirmala Shenoy, Paulo Mendes, Donald Eastlake, Peng Liu, 2021-07-12, 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 issues identified in this document are complemented and deepened by a detailed gap analysis in a separate companion document [GAP_ANALYSIS]. "Dynamically Recreatable Keys", Juan Garcia-Pardo, Cyrill Krahenbuhl, Benjamin Rothenberger, Adrian Perrig, 2021-07-12, 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. "Associated Channel over IPv6", Fan Yang, Mach Chen, Tianran Zhou, 2021-07-12, This document introduces a control channel based on IPv6, called Associated CHannel over IPv6 (ACH6), that may carry different types of control and management messages. By using the associated channel, messages can be transmitted between network nodes to provide functions like path identification, OAM, automatic protection switchover signaling, resource reservation, etc., targeting to provide high quality SLA guarantees to IPv6 services. "IGP Extensions for SR Slice Aggregate SIDs", Tarek Saad, Vishnu Beeram, Ran Chen, Shaofu Peng, Bin Wen, Daniele Ceccarelli, 2021-09-16, 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 that enable advertising Slice Aggregate SR segments that share the same IGP computed forwarding path but offer a forwarding treatment (e.g. scheduling and drop policy) that is associated with a specific Slice Aggregate. "NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol", Martin Langer, Rainer Bermbach, 2021-08-20, 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. "RPKI Validation Re-reconsidered", Job Snijders, Ben Maddison, 2021-09-02, This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6482. This document updates RFC 6487. This document obsoletes RFC 8360. "YANG Data Model for Slice Policy", Tarek Saad, Vishnu Beeram, Bin Wen, Daniele Ceccarelli, Shaofu Peng, Ran Chen, Luis Contreras, Xufeng Liu, 2021-07-12, A slice policy is a policy construct that enables instantiation of mechanisms in support of IETF network slice specific control and data plane behaviors on select topological elements. This document defines a YANG data model for the management of slice policies on slice policy capable nodes and controllers in IP/MPLS networks. "Enhancing Transport Protocols over Satellite Networks", Tom Jones, Gorry Fairhurst, Nicolas Kuhn, John Border, Stephan Emile, 2021-10-13, IETF transport protocols such as TCP, SCTP and QUIC are designed to function correctly over any network path. This includes networks paths that utilise a satellite link or network. While transport protocols function, the characteristics of satellite networks can impact performance when using the defaults in standard mechanisms, due to the specific characteristics of these paths. [RFC2488] and [RFC3135] describe mechanisms that enable TCP to more effectively utilize the available capacity of a network path that includes a satellite system. Since publication, both application and transport layers and satellite systems have evolved. Indeed, the development of encrypted protocols such as QUIC challenges currently deployed solutions, for satellite systems the capacity has increased and commercial systems are now available that use a range of satellite orbital positions. This document describes the current characterises of common satellite paths and describes considerations when implementing and deploying reliable transport protocols that are intended to work efficiently over paths that include a satellite system. It discusses available network mitigations and offers advice to designers of protocols and operators of satellite networks. "Privacy Improvements for DNS Resolution with Confidential Computing", Jari Arkko, Jiri Novotny, 2021-07-02, Data leaks are a serious privacy problem for Internet users. Data in flight and at rest can be protected with traditional communications security and data encryption. Protecting data in use is more difficult. In addition, failure to protect data in use can lead to disclosing session or encryption keys needed for protecting data in flight or at rest. This document discusses the use of Confidential Computing, to reduce the risk of leaks from data in use. Our example use case is in the context of DNS resolution services. The document looks at the operational implications of running services in a way that even the owner of the service or compute platform cannot access user-specific information produced by the resolution process. "Segment Routed Time Sensitive Networking", Yaakov Stein, 2021-08-29, Routers perform two distinct user-plane functionalities, namely forwarding (where the packet should be sent) and scheduling (when the packet should be sent). One forwarding paradigm is segment routing, in which forwarding instructions are encoded in the packet in a stack data structure, rather than programmed into the routers. Time Sensitive Networking and Deterministic Networking provide several mechanisms for scheduling under the assumption that routers are time synchronized. The most effective mechanisms for delay minimization involve per-flow resource allocation. SRTSN is a unified approach to forwarding and scheduling that uses a single stack data structure. Each stack entry consists of a forwarding portion (e.g., IP addresses or suffixes) and a scheduling portion (deadline by which the packet must exit the router). SRTSN thus fully implements network programming for time sensitive flows, by prescribing to each router both to-where and by-when each packet should be sent. "Multi-purpose Special Purpose Label for Forwarding Actions", Kireeti Kompella, Vishnu Beeram, Tarek Saad, Israel Meilik, 2021-07-12, A Slice Selector is packet metadata that dictates the packet's forwarding handling in order to conform to its slice requirements. There are multiple proposals for carrying slice selectors in MPLS networks. One of the more practical proposals is the "Global Identifier for Slice Selector" (GISS). Global uniqueness requires the GISS label be identified as such, via a special purpose label (ideally a base special purpose label (bSPL)). However, bSPLs are a precious commodity, and there are many requests for them. This document serves two purposes: to define a bSPL for carrying a GISS, and to show how this bSPL can consolidate many current requests for special purpose labels while carrying associated data compactly and efficiently. "SRH and IP header protection", Dongjie Lu, chenmeiling, Li Su, Wei Pan, Cheng Li, 2021-06-28, 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. "Instantiation of IETF Network Slices in Service Providers Networks", samier barguil, Luis Contreras, Victor Lopez, Reza Rokui, Oscar de Dios, 2021-07-12, 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 and (e.g., Layer-3 Service Model, Layer-2 Service Model) and Network Models (e.g., Layer-3 Network Model, Layer-2 Network Model) 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, it needs to map it 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. "Key Consistency and Discovery", Alex Davidson, Matthew Finkel, Martin Thomson, Christopher Wood, 2021-08-19, This document describes the key consistency and correctness requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It discusses several mechanisms and proposals for enabling user privacy in varying threat models. In concludes with discussion of open problems in this area. "BGP Color-Aware Routing (CAR)", Dhananjaya Rao, Swadesh Agrawal, Clarence Filsfils, Ketan Talaulikar, Dirk Steinberg, Luay Jalil, Yuanchao Su, Jim Guichard, Keyur Patel, Haibo Wang, 2021-05-11, 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). "Definition of End-to-end Encryption", Mallory Knodel, Fred Baker, Olaf Kolkman, Sofia Celi, Gurshabad Grover, 2021-07-12, End-to-end encryption (E2EE) is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability. Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. "Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation", Carsten Bormann, 2021-09-06, 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 often is 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 SRT Protocol", Maria Sharabayko, Maxim Sharabayko, Jean Dube, Joonwoong Kim, Jeongseok Kim, 2021-09-07, This document specifies Secure Reliable Transport (SRT) protocol. SRT is a user-level protocol over User Datagram Protocol and provides reliability and security optimized for low latency live video streaming, as well as generic bulk data transfer. For this, SRT introduces control packet extension, improved flow control, enhanced congestion control and a mechanism for data encryption. "The Privacy Token HTTP Authentication Scheme", Tommy Pauly, Frederic Jacobs, Christopher Wood, 2021-09-07, This documents defines an authentication scheme for HTTP called Privacy Token. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. "Test Protocol for One-way IP Capacity Measurement", Len Ciavattone, Alfred Morton, 2021-07-12, This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC xxxx: draft-ietf-ippm-capacity- metric-method, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. It supplies a simple protocol to perform the measurements. See Section 10: The authors seek feedback to determine what additional features will be necessary for an IETF Standards Track Protocol, beyond what is present in the running code available now. "Randomized and Changing MAC Address Use Cases", Jerome Henry, Yiu Lee, 2021-05-03, To limit the association between a device traffic 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 environements and a set of network services that may be affected by such rotation. This document then examines settings where the user experience may be affected by in-network state disruption, and settings where other machine identifiers may expose the user privacy. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. "Updating References to the IETF FTP Service", Roman Danyliw, 2021-10-21, The IETF FTP service running at ftp.ietf.org, ops.ietf.org and ietf.org will be retired. A number of published RFCs in the IETF and IAB streams include URIs that reference this FTP service. To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs. "The Time Zone Information Format (TZif)", Arthur Olson, Paul Eggert, Kenneth Murchison, 2021-09-19, This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. "Scalable Remote Attestation for Systems, Containers, and Applications", Kathleen Moriarty, Antonio Fontes, 2021-06-04, This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, preventing the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). "PKI-Authenticated Certificate Discovery Using DANE TLSA records", Ash Wilson, Shumon Huque, 2021-09-13, The DNS-Based Authentication of Named Entities (DANE) TLSA specification [RFC6698] and The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance [RFC7671] describe how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates [RFC6698] and [RFC7671]. It describes how to use the TLSA record to enable entity and CA certificate discovery for object security and trust chain discovery use cases, and how to use PKIX validation for TLSA records queried without the benefit of DNSSEC. "Survey of Domain Verification Techniques using DNS", Shivan Sahib, Shumon Huque, 2021-06-10, Many services on the Internet need to verify ownership or control of domains in the Domain Name System (DNS) [RFC1034] [RFC1035]. This verification often relies on adding or editing DNS records within the domain. This document surveys various techniques in wide use today, the pros and cons of each, and possible improvements. 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/ShivanKaul/draft-sahib-domain-verification- techniques. "DLEP Radio Quality Extension", Henning Rogge, 2021-08-09, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. "The Base45 Data Encoding", Patrik Faltstrom, Fredrik Ljunggren, Dirk-Willem van Gulik, 2021-07-01, This document describes the Base45 encoding scheme which is built upon the Base64, Base32 and Base16 encoding schemes. "A SIP Response Code (497) for Call Transfer Failure", Shrawan Khatri, Vikram Singh, Marcelo Pazos, Cherng-Shung Hsu, Yong Xie, 2021-07-27, 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. "CoAP Protocol Indication", Christian Amsuess, 2021-07-10, 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 based on Web Linking [RFC8288] to express alternative transports available to a device, and to optimize exchanges using these. "Security Technical Specification for Smart Devices of IoT", Bin Wang, Xing Wang, Li Wan, Wenyuan Xu, Chonghua Wang, 2021-09-15, With the development of IoT, security of smart devices becomes an important issues for us to discuss. This draft for smart devices of Internet of Things (IoT), 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 interface security and security 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. "The LIMITS SMTP Service Extension", Ned Freed, 2021-07-12, This document defines a "Limits" extension for the Simple Mail Transfer Protocol (SMTP), including submisssion, 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. "Technical Requirements for Secure Access and Management of IoT Smart Terminals", Bin Wang, Song Liu, Li Wan, Jun Li, Xing Wang, 2021-09-14, 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. "Guidelines for the Organization of Fully Online Meetings", Mirja Kuehlewind, Martin Duke, 2021-05-18, This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience after the COVID-19 pandemic in 2020. "Structured Flow Label", Clarence Filsfils, Ahmed Abdelsalam, Shay Zadok, Xiaohu Xu, Weiqiang Cheng, Dan Voyer, Pablo Camarillo, 2021-09-07, This document defines the IPv6 Structured Flow Label. The seamless nature of the change to [RFC6437] is demonstrated. Benefits of the solution are explained. Use-cases are illustrated. "LISP Transport for Policy Distribution", Michael Kowal, Marc Portoles-Comeras, Amit Jain, Dino Farinacci, 2021-09-15, 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, 2021-09-14, 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. "IPv6 Oversized Packets Analysis", Eduard, XiPeng Xiao, Dmitriy Khaustov, 2021-09-18, The IETF has some initiatives relying on IPv6 Extension Headers added in transit: SRv6, iOAM. Additionally, some recent developments are overlays (SRv6, VxLAN, NVO3, L2TPv3, and LISP). It could create oversized packets that need to be dealt with. This document analyzes available standards for the resolution of oversized packet drops. "Fetch and Validation of Verified Mark Certificates", Wei Chuang, Marc Bradshaw, Thede Loder, Alex Brotman, 2021-10-11, 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, 2021-10-11, 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. "Automatic Extended Route Optimization (AERO)", Fred Templin, 2021-10-15, This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) interfaces. AERO/OMNI use an IPv6 link-local address format that supports operation of the IPv6 Neighbor Discovery (IPv6 ND) protocol. Prefix delegation/registration services are employed for network admission and to manage the IP forwarding and routing systems. Secure multilink operation, mobility management, multicast, traffic path selection and route optimization are naturally supported through dynamic neighbor cache updates. AERO is a widely-applicable mobile internetworking service especially well-suited to aviation services, intelligent transportation systems, mobile end user devices and many other applications. "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, Tony Whyman, 2021-10-15, Mobile network platforms and devices (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over multiple access network data links and configure mobile routers to connect end user networks. A multilink interface specification is presented that enables mobile nodes to coordinate with a network-based mobility service and/or with other mobile node peers. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. "Deprecating infrastructure "int" domains", Kim Davies, Amanda Baber, 2021-10-14, The document marks as historic any "int" domain names that were designated for infrastructure purposes, and identifies them for removal from the "int" top-level domain. Any implementation that involves these domains should be considered deprecated. This document also updates RFC 1591 by removing the documented use of "int" for international databases. "Common Format and MIME Type for Comma-Separated Values (CSV) Files", Yakov Shafranovich, 2021-09-19, 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, 2021-10-07, This document specifies a method for DNS resolvers to publish information about themselves. Clients can use the resolver information to identify the capabilities of DNS resolvers. "IETF Discussion List Charter", Lars Eggert, 2021-10-11, The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of topics for which no dedicated mailing lists exists. As this is the most general IETF mailing list, considerable latitude is allowed, but there are posts and topics that are unsuitable for this mailing list. This document obsoletes RFC3005. "Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)", Kenneth Vaughn, 2021-06-27, This document updates the TLS Transport Model (TLSTM), as defined in [RFC6353], to support Transport Layer Security Version 1.3 (TLS) [RFC8446] and Datagram Transport Layer Security Version 1.3 (DTLS) [I-D.ietf-tls-dtls13], which are jointly known as "(D)TLS". This document may be applicable to future versions of SNMP and (D)TLS. This document updates the SNMP-TLS-TM-MIB as defined in [RFC6353]. "Status of this Memo", Fotis Foukalas, Athanasios Tziouvaras, 2021-09-27, Next generation Internet requires decentralized and distributed intelligence in order to make available a new type of experience to serve the user's interests. Such new services will be enabled by deploying the intelligence over a high volume of IoT devices in a form of distributed protocol. Such a protocol will orchestrate the machine learning (ML) application in order to train the aggregated data available from the IoT devices. The training is not an easy task in such a distributed environment, where the amount of connected IoT devices will scale up and the needs for both interoperability and computing are high. This draft, addresses both issues by combining two emerging technologies known as edge AI and fog computing. The protocol procedures aggregate the data collected by the IoT devices into a fog node and apply edge AI for data analysis at the edge of the infrastructure. The analysis of the IoT requirements resulted in an end-to-end ML protocol specification which is presented throughout this draft. "An in-band BGP mechanism for looking-glass address discovery", Rayhaan Jaufeerally, 2021-07-25, Autonomous Systems (ASes) that peer with one another using the Border Gateway Protocol (BGP) RFC 4271 [RFC4271] do not have an automated way to tell if the prefixes announced over a particular peering link are acceped by the peer. One way in which an AS operator can verify acceptance of routes by a peer is using a looking glass which may be provided by the peer, however this introduces manual toil in the operation and turnup of peering links, and does not allow for continued validation to ensure there are no regressions. Looking glasses are often manually found by browsing the website of the peer or via a database of peering participants. This document proposes a new in-band mechanism for transmitting administrative data between BGP peers, and defines one such use case for propagating looking glass addresses. This is done via a new Address Family Identifier (AFI) which carries a message that we define here, inside the Multi Protocol (MP_REACH and MP_UNREACH) path attribute The looking glass that we expose via the proposed mechanism conforms to that defined in RFC 8522 [RFC8522]. "General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates", Tadahiko Ito, Tomofumi Okubo, Sean Turner, 2021-07-12, [RFC5280] specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key usage for X.509 public key certificates which restricts the usage of the certificates for document signing. "Map-like data in CBOR and CDDL", Carsten Bormann, Brendan Moran, Henk Birkholz, Emile Cormier, 2021-06-01, 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. Basic CBOR supports non-ordered maps free of duplicate keys, similar to the way JSON defines JSON objects (RFC 8259). Using the CBOR extension point of tags, tags for a selection of variants of maps and multimaps have been registered, but gaps remain. The present document defines a consolidated set of CBOR tags for map-like data items involving key-value pairs. The Concise Data Definition Language (CDDL), standardized in RFC 8610, is often used to express CBOR data structure specifications. It provides "control operators" as its main language extension point. The present document defines a number of control operators that enable the description of CBOR data structures that make use of the newly defined tags or that employ the same underlying structures. "LAG indication", Bruno Decraene, Shraddha Hegde, 2021-10-06, 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. "TAPS Transport Discovery", Martin Duke, 2021-10-05, The Transport Services architecture decouples applications from the protocol implementations that transport their data. While it is often straightforward to connect applications with transports that are present in the host operating system, providing a means of discovering user-installed implementations dramatically enlarges the use cases. This document discusses considerations for the design of a discovery mechanism and an example of such a design. Discussion of this work is encouraged to happen on the TAPS IETF mailing list taps@ietf.org or on the GitHub repository which contains the draft: https://github.com/martinduke/draft-duke-taps-transport- discovery. "Sequence Number Extension for Windowed Protocols", Joseph Touch, 2021-10-06, Sliding window protocols use finite sequence numbers to determine segment placement and order. These sequence number spaces wrap around and are reused during the operation of such protocols. This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header. The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection. "Token Cell Routing Data Plane Concepts", Stewart Bryant, Alexander Clemm, 2021-10-19, Token Cell Routing is a powerful yet hardware friendly method of constructing data plane packets to meet the needs of new applications. It is based on the use of token cells (special kinds of lightly structured tokens) to provide pointers to procedures pre- positioned in the forwarding layer together with the parameters needed to provide the required processing context. A packet can be composed from multiple token cells as needed to result in new new network processing and forwarding semantics. "ND Prefix Robustness Improvements", Eduard, Paolo Volpato, Loba Olopade, 2021-10-14, 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. "YANG Model for Scalable VTN", Xuesong Geng, Zhibo Hu, 2021-06-03, This document defines the Yang data model for scalable Virtual Transport Network(VTN). "IS-IS Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-07-27, This document describes IS-IS extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. "OSPF Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-07-27, This document describes OSPF 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, 2021-07-27, This document describes OSPFv3 extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. "Data Transmission Security of Identity Resolution in Industrial Internet", Bin Wang, Kezhang Lin, Chonghua Wang, Xing Wang, 2021-10-11, 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. "Deterministic Networking (DetNet): Packet Ordering Function", Balazs Varga, Janos Farkas, Stephan Kehrer, Tobias Heer, 2021-05-21, 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. "IGP Extensions to Support Flex-Algorithm Aware Traffic Engineering", Ran Chen, Shaofu Peng, 2021-04-20, [I-D.ietf-lsr-flex-algo]proposes a solution that allows IGPs themselves to compute constraint based paths over the network, and it also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. [RFC8570] describes IS-IS extensions to distribute network- performance information (such as residual bandwidth, and available bandwidth). This draft describes the IGP extensions to advertise the corresponding network-performance information of the Flex-Algorithm. "Border Gateway Protocol 4 (BGP-4) Send Hold Timer", Job Snijders, Ben Cartwright-Cox, 2021-10-17, 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 tear down when BGP timers have expired. This document updates RFC4271. "Retrieving information about Object Identifiers using a text-based protocol", Daniel Marschall, 2021-09-30, This document defines a method for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) using a text-based protocol, in a way that is both human-readable and machine-readable. "A File Format for the Discoverable Use of Analytics", Frederik Ring, Hendrik Niefeld, 2021-08-18, Internet privacy has become an important feature for users of websites and services. This document proposes a way for websites and services to declare and disclose their usage of analytics and tracking software. analytics.txt aims to be an elaborate file format that describes the privacy related characteristics of analytics and tracking software in a non-biased way. An analytics.txt file is understandable for a non-technical audience, while also useful for the automated consumption by tools and software. "Flexible Algorithm with Bandwidth Constrains", Liu Yao, Shaofu Peng, 2021-04-22, This document proposes extensions for IGP to allow the computation based on bandwidth constraints together with the existing metric in Flexible Algorithm. "Segment Routing for End-to-End IETF Network Slicing", Zhenbin Li, Jie Dong, 2021-04-22, Network slicing can be used to meet the connectivity and performance requirement of different services or customers in a shared network. An IETF network slice can be realized as enhanced VPNs (VPN+), which is delivered by integrating the overlay VPN service with a Virtual Transport Network (VTN) as the underlay. 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 a local VTN. When segment routing (SR) is used to build a multi-domain IETF network slice, information of the local network slices in each domain can be specified using special SR binding segments called VTN binding segments (VTN BSID). The multi-domain IETF network slice can be specified using a list of VTN BSIDs in the packet, each of which can be used by the corresponding domain edge nodes to steer the traffic of end-to-end IETF network slice into the specific VTN in the local domain. This document describes the functionality of VTN binding segment and its instantiation in SR-MPLS and SRv6. "QUIC Version 2", Martin Duke, 2021-07-09, This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. Over time, it may also serve as a vehicle for needed protocol design changes. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org or on the GitHub repository which contains the draft: https://github.com/martinduke/draft-duke-quic-v2. "HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Hongqiang Liu, Rong Pan, Jeongkeun Lee, Changhoon Kim, Barak Gafni, Yuval Shpigelman, 2021-04-22, 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. "Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou, Lifen Zhou, 2021-04-25, 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 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). "Direct Anonymous Attestation for the Remote Attestation Procedures Architecture", Henk Birkholz, Christopher Newton, Liqun Chen, 2021-07-12, This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The role DAA Issuer is introduced and its interactions with existing RATS roles is specified. "Attestation Results for Secure Interactions", Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata, 2021-09-07, This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. "Packetised Essence Format for Uncompressed Video", James Weaver, 2021-04-27, This memo specifies a new proposed packing format for Uncompressed video data at a variety of bit-depths and with a variety of different component structures. "BGP Flowspec Explicit Term Ordering", Jeffrey Haas, Susan Hares, Sven Maduschke, 2021-04-27, BGP Flowspec (RFC 8955) provides a mechanism for matching traffic flows. The ordering of the Flow Specifications defined by that RFC is provided by a sorting function that uses the contents of the received BGP NLRI; that NLRI does not contain an explicit ordering component. The RFC's sorting function permits for origination of Flowspec NLRI from multiple BGP Speakers and is generally appropriate for mitigating distributed denial-of-service (DDoS) attacks. There are circumstances where the implicit RFC 8955 sorting order is not appropriate. This document defines a mechanism that permits individual Flowspec NLRI to influence their sort order. "A collaborative Edge-Cloud framework for XR applications", Rohit Abhishek, 2021-04-27, This document discusses a collaborative edge-cloud model and application of network slicing for Extended Reality (XR), including both Augmented Reality (AR) and Virtual Reality (VR), especially with respect to the architectural framework and "QoS" based optimal latency tolerant resource allocation. "AMP Mesh Protocol", Aljoscha Schulte, 2021-04-28, This memo describes a decentralized multi-domain mesh networking protocol for low power embedded systems. Its decentralized architecture allows for large scale dynamic topologies across multiple wireless domains. The protocol is optimized for low power wireless devices by using zero-maintenance addressing algorithms. A decentralized ad-hoc reactive routing algorithm enables fast route convergence with low communication overhead. "Number of Generic Associated Channel Labels in the MPLS Label Stack", Greg Mirsky, Huub van Helvoort, Stewart Bryant, Alexander Vainshtein, Italo Busi, 2021-04-28, This document describes the requirements for using multiple Generic Associated Channel Labels (GALs) in an MPLS label stack. As a result, the document updates RFC 5586 by removing the restriction imposed on the usage of GAL that limits the number of GAL in the MPLS label stack to one. "MPLS Open Design Team Questions", Loa Andersson, 2021-05-10, This document is a living document, meaning that during the life timme of the MPLS Open Design Team we will put additonal questions/ issues into the document. When we find an answer amd a way to document the issu it will be removed from this document. Ideally when the Design Team is closed this document will be empty, or maybe we just add a pointer to where the answer to quesstion is documented. Thus this document will never go on to become an RFCc. "Password-based key protection", Karelina Ekaterina, 2021-04-30, This document supplements [RFC8018]. It contains the specifications of the cryptographic algorithms defined by the Russian national standards for their implementation of generating general key in the password-based schemes. "Common Features for Encrypted Recursive to Authoritative DNS", Peter van Dijk, Paul Hoffman, 2021-06-16, Encryption between recursive and authoritative DNS servers is currently being defined in two modes: unauthenticated and fully- authenticated. These two modes have some features in common, and this document defines those common features so that the documents defining the modes do not need to point to each other. "Reserving Additional IPv6 Address Prefixes for Use in Documentation", Ed Horley, Tom Coffeen, Scott Hogg, Nick Buraglio, Chris Cummings, Kevin Myers, Russ White, 2021-07-27, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, the IPv6 unicast address prefix 2001:db8::/32 is reserved for use in examples in documentation including RFCs, books, articles, vendor manuals, etc. This document proposes the reservation of additional IPv6 prefixes for this purpose; specifically, 3ffe::/16 (formerly 6bone) and fec0::/10 (formerly site-local). "The DAKAMI RRTYPE", Paul Wouters, 2021-05-03, This document specifies a new DNS RR type DAKAMI. It is used to signify and honor the impact of security researcher Dan Kaminsky on the DNS ecosystem. "More Accurately Naming IPv6 RA Router Lifetime", Mark Smith, 2021-05-04, IPv6 Router Advertisements (RAs) have a "Router Lifetime" field, which specifies how long the advertising router will act as a default router for the receiving hosts, unless refreshed with another advertisement. The field name "Router Lifetime" is quite general, and could easily be misunderstood to mean the bounded lifetime of all of the information contained in the RA. This memo more accurately renames this field "Default Router Lifetime". "Protected QUIC Initial Packets", Martin Duke, David Schinazi, 2021-05-13, QUIC encrypts its Initial Packets using keys derived from well-known constants, meaning that observers can inspect the contents of these packets and successfully spoof them. This document proposes a new version of QUIC that encrypts Initial Packets more securely by leveraging a Public Key distributed via the Domain Name System (DNS) or other out-of-band system. "Network Time Security for the Unicast Mode of the Precision Time Protocol", Heiko Gerstung, Marius Rohde, Doug Arnold, 2021-06-04, This memo specifies the application of Network Time Security, a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the unicast mode of the Precision Time Protocol. It is based on the 'Network Time Security for the Network Time Protocol' document RFC8915 and re-uses most of its mechanisms for providing a secure and robust key exchange solution for unicast PTP. Due to the different modes of operation, additional steps are required to secure unicast PTP communication between the PTP clients and unicast PTP servers. In addition to defining the new record types and other required values to allow the utilization of the NTS key exchange sub protocol, there are a number of additional protocol enhancements and server-side requirements which are defined in this memo. "Bundle Protocol Extended Class of Service (ECOS)", Scott Burleigh, Fred Templin, 2021-05-05, This document describes an extension to the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) that marks bundles with class-of-service designators. The class-of-service designators are an "ordinal" number that provides fine-grained prioritization of bundles, a "critical" flag, flags that explicitly request "timely" or "assured" convergence-layer transmission (or both), and an optional QoS tag. "A Survey of Semantic Internet Routing Techniques", Daniel King, Adrian Farrel, 2021-06-28, The Internet Protocol (IP) has become the global standard in any computer network, independent of the connectivity to the Internet. Generally, an IP address is used to identify an interface on a network device. Routing protocols are also required and developed based on the assumption that a destination address has this semantic with routing decisions made on addresses and additional fields in the packet headers. Over time, routing decisions were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers. Many proposals have been made to add semantics to IP addresses. The intent is usually to facilitate routing decisions based solely on the address and without the need to find and process information carried in other fields within the packets. This document is presented as a survey to support the study and 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 "AC-Influenced DF Election per EVI", Yubao Wang, 2021-07-11, The AC-influenced DF Election (AC-DF) per [RFC8584] is too dependent on EAD/EVI routes. For example, when no failures occured on an ESI, that AC-DF procedures will give incorrect results if no EAD/EVI routes are advertised. But in some light-weighted EVPNs (i.e. PBB EVPNs), no EAD/EVI routes will be advertised at all. This draft proposes some new extensions to support AC-influenced DF Election without any EAD/EVI routes advertised in advance of any failures. "A Duck Test for End-to-End Secure Messaging", Alec Muffett, 2021-07-12, This document defines End-to-End Secure Messaging in terms of behaviours that MUST be exhibited by software that claims to implement it, or which claims to implement that subset which is known as End-to-End Encrypted Messaging. "BGP Tunnel Encapsulation Attribute Extensions for Network Slicing", Shaofu Peng, Liu Yao, 2021-05-09, This document defines extension to BGP Tunnel Encapsulation attribute to provide network slicing information needed to create tunnels and their corresponding encapsulation headers. "I-Regexp: An Interoperable Regexp Format", Carsten Bormann, 2021-05-12, "Regular expressions" (regexps) are a set of related, widely implemented pattern languages used in data modeling formats and query languages that is available in many dialects. This specification defines an interoperable flavor of regexps, I-Regexp. The present version -00 of this document is a trial balloon, meant to determine whether this approach is useful for the JSONPath WG. "PEAA: Privacy-Enhanced Access Authentication Scheme in 5G", Xixiang Lyu, Xinyue Yao, Dong Ma, Ronghui Hou, Jin Cao, Xinhong Mao, 2021-05-13, Authentication and Key Agreement (AKA) protocol aims to enable mutual authentication between networks and a phone equipped with a Universal Subscriber Identity Module(USIM) card. 5G AKA introduces Subscription Permanent Identifier (SUPI) and Elliptic Curve Integrated Encryption Scheme (ECIES) to preserve user identity privacy. However, when the authentication server becomes an unsecure entity due to malwares or malicious attacks, these existing schemes cannot effectively protect user identity privacy at the server-end. For a small number of important users with high demand for identity privacy and security, comprehensive identity privacy protection is one of their important security requirements. Based on a security assumption that the server is trustworthy within a limited time, this document proposes a privacy-enhanced access authentication scheme (PEAA) which is compatible with 5G AKA. This scheme not only achieves user anonymity on wireless channels by dynamic temporary pseudonyms, but also ensures that the server authenticates users without their permanent identities. In the context of hierarchical security requirements, PEAA scheme and the existing 5G AKA can respectively provide different user identity privacy protection services for users with different security requirements. "Internet of Secure Elements", Pascal Urien, 2021-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). "CoAP Attacks", John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess, 2021-07-27, 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. This document summarizes a number of known attacks on CoAP and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. The document also summarizes different denial-of-service attacks using CoAP. The goal with this document is motivating generic and protocol-specific recommendations on the usage of CoAP. Several of the discussed attacks can be mitigated with the solutions in draft-ietf-core-echo-request-tag. "Discovery of Encrypted DNS Resolvers: Deployment Considerations", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook, Tommy Jensen, 2021-05-17, The document discusses some deployment considerations of the various options to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS- over-TLS, DNS-over-QUIC). "Interflow vs Intraflow Delays", Jonathan Morton, Peter Heist, 2021-05-17, Much current literature discusses queuing delays, and the effects of different queue disciplines, active queue management algorithms, and congestion control measures on these delays. This draft highlights an important distinction between different types of delay, which may be helpful to practitioners and theoreticians alike. "Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers", Gabor Lencse, Keiichi Shima, 2021-10-10, 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 NAT (NAT44, NAT64, NAT66) technologies. We discuss why using pseudorandom port numbers with stateful NAT gateways is a hard problem and recommend a solution. "PCEP Procedures and Extension for VLAN-based Traffic Forwarding", Wang Yue, Aijun Wang, 2021-10-19, This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. "Use of an MPLS LSE as an Ancillary Data Pointer", Stewart Bryant, Alexander Clemm, Toerless Eckert, 2021-05-18, 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, 2021-05-21, 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. "Attestation of File Content using an X.509 Certificate", Chuck Lever, 2021-05-28, This document describes a compact open format for transporting and storing an abbreviated form of a cryptographically signed hash tree. Receivers use this representation to reconstitute the hash tree and verify the integrity of file content protected by that tree. An X.509 certificate encapsulates and protects the hash tree metadata and provides cryptographic provenance. Therefore this document updates the Internet X.509 certificate profile specified in RFC 5280. "BGP Flow Specification for DetNet Flow Mapping", Quan Xiong, Haisheng Wu, 2021-05-27, 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. "Use Case for P4 Programmability by Tenants of Future Mobile Virtual Networks", Xavier de Foy, 2021-05-27, Support for multi-tenancy has been the subject of recent work on P4 switch programming. This draft further describes a potential use case where a tenant programs a virtual network built over a mobile network, and discusses related requirements. The use case is based on the existing 5GLAN feature, since it is a well documented virtual network architecture supported by 5G. "Use TEE Identification in EAP-TLS", Penglin Yang, chenmeiling, Li Su, 2021-08-06, In security considerations, identity of a device should be protected and cannot be exposed in public in plaintext. The storage and execution of identity in device also need to be protected during the lifecycle. Based on this purpose, this document uses TEE and EAP-TLS to create a secure and trusted procedure to authenticate a device's identity. In this architecture, certificate protection and handshake keys generation which are used for EAP-TLS authentication will be executed in TEE. Communication establishment with EAP-TLS Server will be executed in REE. A middle layer is introduced to communicate between TEE and REE to compose the original function of EAP-TLS Client. TEE identification based on EAP-TLS could be used in different network layers to implement identity authentication. "Effective DNS Service", Rintaro Kobayashi, 2021-06-01, In DNS Queries over HTTPS [RFC8484], the port that communicates with DNS would change from UDP to TCP 443. This change causes a new problem that makes it difficult to identify which is the name resolution request, so it is difficult to use web filtering, parental controls and so on. Furthermore, a user-agent in a HTTP header that is necessary for HTTPS communications could be a data used to track users. In summary, DNS Queries over HTTPS has some problems that affect users' security and privacy. This draft proposes a system that is set mediation servers between client side and DNS servers. With this proposal, it is expected that those two problems will be solved. "Pairing Friendly Curves Representations in JOSE and COSE", Kyle Hartog, 2021-06-01, This specification defines representations enabling the Standards for Pairing Frinedly Curves to be used for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) messages. "IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option", Nalini Elkins, mackermann@bcbsm.com, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, 2021-10-19, 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. "Path Selection for Multiple Paths In QUIC", Spencer Dawkins, 2021-06-02, In QUIC working group discussions about proposals to use multiple paths, an obvious question came up - given multiple paths, how does QUIC select paths to send packets over? The answer to that question may inform decisions in the QUIC working group about the scope of any multipath extensions considered for experimentation and adoption. This document is intended to summarize aspects of path selection from those contributions and conversations. It is recognized that path selection is not the only important open question about QUIC Multipath, but other open questions are out of scope for this document. "Data Fields Encapsulation Model of In-situ OAM in SRv6 Network", Yuanxiang Qiu, Jinrong Ye, Hao Li, 2021-06-03, 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 OAM information within the packet while the packet traverses a particular network domain. The term "in-situ" refers to the fact that the IOAM data fields are added to the data packets rather than being sent within probe packets specifically dedicated to OAM. This document defines the data fields encapsulation model of IOAM TLV in SRv6 network. "RADIUS Extensions for Encrypted DNS", Mohamed Boucadair, Tirumaleswar Reddy.K, 2021-06-21, This document specifies new Remote Authentication Dial-In User Service (RADIUS) attributes that carry an authentication domain name, a list of IP addresses, and a set of service parameters of encrypted DNS resolvers. "BGP Over QUIC", Shuanglong Chen, Yongkang Zhang, Haibo Wang, Zhenbin Li, 2021-06-03, Border Gateway Protocol (BGP) is an autonomous system routing protocol. The main function of BGP is to exchange routing and reachability information between autonomous systems(AS) on the Internet. BGP uses TCP to implement reliable and orderly transmission of information. Similar to TCP, QUIC is a UDP-based, byte-stream-based reliable data transmission service. In addition, by integrating with TLS 1.3, QUIC also supports functions such as establishing connections with minimum latency and providing confidentiality and integrity protection for the transmitted data, and multi-stream multiplexing. Taking use of QUIC for BGP can achieve the possible advantages. This document defines the mechanism of BGP over QUIC to and corresponding procedures. "Account based authentication for DHCP", Yibin Xu, Hao Weiguo, Jianping Xie, 2021-06-03, This document describes the mutual authentication between DHCP server and DHCP client based on account information to mitigate the security risk caused by rogue DHCP server, and the problem of illegal DHCP client exhausting DHCP server address. "Expanding the IPv6 Lab Use Space", Ed Horley, Tom Coffeen, Scott Hogg, Nick Buraglio, Chris Cummings, Kevin Myers, Russ White, 2021-07-27, To reduce the likelihood of addressing conflicts and confusion between lab deployments and non-lab (i.e., production) deployments, an IPv6 unicast address prefix is reserved for use in lab, proof-of- concept, and validation networks as well as for for any similar use case. This document describes the use of the IPv6 address prefix 0200::/7 as a prefix reserved for this purpose (repurposing the deprecated OSI NSAP-mapped prefix). "Deterministic Networking (DetNet): OAM Functions for The Service Sub-Layer", Balazs Varga, Janos Farkas, 2021-06-06, 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 requires a new mechanism. This draft introduces OAM related procedures for the DetNet service sub-layer functions. "A VTN Network YANG Module", Bo Wu, Dhruv Dhody, 2021-06-06, This document defines a virtual transport network (VTN) network YANG module for retrieving and manipulating VTN topology and resource allocation. The model can be used to implement the provisioning of IETF network slice services. "Gateway Identification and Discovery for Decentralized Ledger Networks", Shiping Chen, Thomas Hardjono, 2021-06-07, Today there is a growth in the number of blockchain and decentralized ledger networks (DLN) around the world, and interoperability across different networks represents a challenge for the value proposition of these networks. One approach for blockchain interoperability to be achieved is to employ gateways that permit assets to flow across the relevant networks of blockchains. However, a core requirement for interoperability is the correct identification of computer systems that act as gateways and the correct validation of the ownership of the gateway. A secondary requirement is for a gateway to inquire as to the existence of an entity address (public key) within a given decentralized ledger network. This memo discusses options with regards gateway identification and verification strategies. It looks at addressing the problem from the application layer and from the network layer. It also discusses other options, such as relying on a third-party blockchain-registered identifiers and resolver services "IPv6 Options for DetNet", Pascal Thubert, Fan Yang, 2021-08-24, RFC 8938, the Deterministic Networking Data Plane Framework relies on the 6-tuple to identify an IPv6 flow. But the full DetNet operations require also the capabilities to signal meta-information such as a sequence within that flow, and to transport different types of packets along the same path with the same treatment, e.g., Operations, Administration, and Maintenance packets and/or multiple flows with fate and resource sharing. This document introduces new IPv6 options that signal that path and redundancy information to the intermediate DetNet relay and forwarding nodes. "Nameserver Access Modes with Encryption Held in Alphanumeric Configuration Keys", Benjamin Schwartz, Warren Kumari, 2021-06-08, Some recent proposals to the DPRIVE working group rely on the use of SVCB records to provide instructions about how to reach an authoritative nameserver over an encrypted transport. These proposals will be difficult to deploy until the parent domain's delegation software has been modified to support these records. As an interim solution for these domains, this draft proposes encoding relevant signals in the child's NS-name. "Indicators and anxillary data in the MPLS Label Stack", Loa Andersson, 2021-06-09, This document is a living document, meaning that during the life timme of the MPLS Open Design Team we will to survey the relationship between indicators and anxillary dat. Ideally when the Design Team is closed this document will be empty, or maybe we just add a pointer to where the answer to quesstion is documented. Thus this document will never go on to become an RFCc. "Deterministic Networking (DetNet): PREOF for DetNet IP", Balazs Varga, Janos Farkas, Andrew Malis, 2021-06-09, This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) based on [RFC9025]. "Requirements and Scenarios for Industry Internet Addressing", Kiran Makhijani, Lijun Dong, 2021-06-10, Industry Control Networks host a diverse set of non-internet protocols for different purposes. Even though they operate in a controlled environment, one end of industrial control applications run over internet technologies (IT) and another over operational technology (OT) protocols. This memo discusses the challenges and requirements relating to converegence of OT and IT networks. One particular problem in convergence is figuring out reachability between the these networks. "Alt-Svc Fixes and Feature Candidates", Erik Nygren, 2021-06-11, HTTP Alternative Services has become the primary mechanism for HTTP/3 upgrade, but overlaps with and disagrees with other developing standards, such as the HTTPS resource record in DNS. This document explores a set of potential fixes and/or additional features for Alt- Svc. It is used to record and share thoughts, and is not expected to progress on its own. "Reinforcement Learning-Based Virtual Network Embedding: Problem Statement", Ihsan Ullah, Youn-Hee Han, TaeYeon Kim, 2021-10-19, In Network virtualization (NV) technology, Virtual Network Embedding (VNE) is an algorithm used to map a virtual network to the substrate network. VNE is the core orientation of NV which has a great impact on the performance of virtual network and resource utilization of the substrate network. An efficient embedding algorithm can maximize the acceptance ratio of virtual networks to increase the revenue for Internet service provider. Several works have been appeared on the design of VNE solutions, however, it has becomes a challenging issues for researchers. To solved the VNE problem, we believe that reinforcement learning (RL) can play a vital role to make the VNE algorithm more intelligent and efficient. Moreover, RL has been merged with deep learning techniques to develop adaptive models with effective strategies for various complex problems. In RL, agents can learn desired behaviors (e.g, optimal VNE strategies), and after learning and completing training, it can embed the virtual network to the subtract network very quickly and efficiently. RL can reduce the complexity of the VNE algorithm, however, it is too difficult to apply RL techniques directly to VNE problems and need more research study. In this document, we presenting a problem statement to motivate the researchers toward the VNE problem using deep reinforcement learning. "Deterministic Nonce-less Hybrid Public Key Encryption", Dan Harkins, 2021-06-14, This document describes two enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys and a determinstic, nonce- less AEAD scheme to increase the utility of the HPKE API. "Fast Transition for Opportunistic Wireless Ecnryption (FT-OWE)", Jerome Henry, Stephen Orr, 2021-06-14, Opportunistic Wireless Encryption, defined in RFC 8110, specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to a specific wireless access point (AP). This memo extends the method to allow the establishment of OWE keying material to other APs before connection establishment, thus enabling a fast transition mode for OWE. "Analysis of DNS Forwarder Scenario Relative to DDR and DNR", Barbara Stark, Chris Box, 2021-06-16, This draft analyzes the behaviors that residential end users and home network owners (e.g., parents of young children) might experience when operating systems and clients support [I-D.ietf-add-ddr] and/or [I-D.ietf-add-dnr] for discovery of encrypted DNS services and the CE router of the home network offers itself as the Do53 resolver. This use case is explicitly mentioned in [I-D.ietf-add-requirements] Section 3.2 and has several requirements related to it. This draft has two goals: determine if the analysis it provides is accurate and, if it is accurate, determine if the behavior is acceptable to the WG or if there should be changes to either of the discovery mechanisms. "Interface Stack Table Definition for Point to Point (P2P) Interface over LAN", Daiying Liu, Joel Halpern, Congjie Zhang, 2021-07-01, In [RFC5309] defines the Point to Point (P2P) circuit type is one of the mainly used circuit types in link state routing protocol, and highlights it is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and monitor the link state. Point to Point (P2P) Interface over LAN ifType value is assigned by IANA experts review. This document provides an example of the ifStack for Point to Point (P2P) Interface over LAN ifType to facilitate operational control, maintenance and statistics. "The Additional Section and Glue in DNS Responses", Paul Hoffman, Peter van Dijk, 2021-06-16, Implementers have recently expressed different views on what can appear in the Additional section in DNS responses. Proposals for adding functionality to the DNS protocol that rely on non-glue records in the Additional section rely on having a common understanding of the semantics of the Additional section. This document restates what has been said in other DNS standards, and does not update any of them. "The Additional Section and Glue in DNS Responses", Paul Hoffman, Peter van Dijk, 2021-06-16, Implementers have recently expressed different views on what can appear in the Additional section in DNS responses. Proposals for adding functionality to the DNS protocol that rely on non-glue records in the Additional section rely on having a common understanding of the semantics of the Additional section. This document restates what has been said in other DNS standards, and does not update any of them. "A Use Case of Packets' Significance Difference with Media Scalability", Lijun Dong, Kiran Makhijani, Richard Li, 2021-10-20, This document introduces a use case of packets' significance difference embedded with media scalability. With the dominance of video traffic on the Internet, selectively dropping packets or parts of packets from competing media streams becomes a complementary mechanism when dealing with network congestion. The document describes the characteristics of media scalability, some limitations of existing end-to-end congestion control mechanisms through rate control and adaptation, explains why current ways of entire packet dropping at the traffic class level using in-network active queue management are not most appropriate to meet end users' Quality of Service expectations. The document identifies that there exists "significance difference" among packets or even among parts of the packets within a flow, and brings out a new set of requirements for application and network to support packet significance difference to improve the Quality of Experience of end users. "OAuth Proof of Possession Tokens with HTTP Message Signatures", Justin Richer, 2021-06-21, This extension to the OAuth 2.0 authorization framework defines a method for using HTTP Message Signatures to bind access tokens to keys held by OAuth 2.0 clients. "Sliding Window Selective Linear Code (SLC) Forward Error Correction (FEC) Scheme for FECFRAME", Ray Wang, Liang Si, Bifeng He, 2021-06-21, This document describes a fully-specified Forward Error Correction (FEC) scheme for Sliding Window Selective Linear Code (SLC) over the Galois Field GF (2^^8). It can be used to selectively protect arbitrary media streams along the lines defined by FECFRAME. It is necessary to protect the media streams selectively (e.g., the reference frames are not continuous under the SVC mode in real-time video streaming transmission). Compared with the traditional Sliding Window FEC Codes, the Sliding Window Selective FEC Code supports that the source symbols in the encoding window are discrete. Therefore, it can be ensured that only source symbols with correlation (whether continuous or not) are included in the encoding window. "Problem Statement and Use Cases of Trustworthiness-based Routing", Tao Lin, Hao Li, Xingang Shi, Xia Yin, Wenlong Chen, 2021-06-21, 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 demand 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. "Limits on Sending and Processing IPv6 Extension Headers", Tom Herbert, 2021-06-22, 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. "An EDNS0 Option for Sharing Pref64::/n", Mohamed Boucadair, 2021-06-23, This document specifies an Extension Mechanisms for DNS (EDNS0) option to convey the IPv6 prefix used to build IPv4-converted IPv6 addresses. When conveyed in a DNS query, the option communicates the IPv6 prefix used in the network from which the query was originated. Such a network is assumed to enable a Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) function. DNS64-capable servers will use that prefix to build synthesized AAAA records, rather than relying on a preconfigured prefix. When conveyed in a DNS reply, the option conveys the IPv6 prefix that is used by a DNS64-capable server to synthesized AAAA records. Such information helps to automatically detect mismatches between the local NAT64 configuration and the one enforced at the DNS64 server. Also, security-aware and validating hosts may use the new EDNS0 option to signal the presence of a NAT64 function. That signal is used by the DNS server to fill the additional section of the AAAA reply in order to supply A RRs of the target. Dual queries and delays are thus avoided. This document updates RFC 6147. "IAB Charter Update for RFC Editor Model", Brian Carpenter, 2021-10-19, This document updates the IAB Charter (RFC 2850) to be consistent with the new model for the RFC Editor (draft-iab-rfcefdp-rfced- model). "L2TP Tunnel keepalive control channel", Yogesh Nautiyal, 2021-06-23, This memo defines a dedicated control channel for L2TP tunnel keepalives for use in deployment which has control plane and user plane seperation. "NTP Over PTP", Miroslav Lichvar, 2021-10-20, This document specifies a transport for the Network Time Protocol (NTP) client-server mode using the Precision Time Protocol (PTP) to enable hardware timestamping on hardware that can timestamp PTP messages but not NTP messages. "SRv6-based BGP Service Capability", Liu Yao, Zheng Zhang, Eduard Metz, 2021-07-11, This draft describes the problems that may be encountered during the deployment of SRv6-based BGP services and the possible solutions. "ALTO for Querying LMAP Results", Chongfeng Xie, Wei Wang, Qiufang Ma, 2021-06-24, Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. The Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol have been developed for measurement task dissemination, initialization, reporting and storing. In the context of Large-Scale Measurement of Broadband Performance (LMAP), measurement results are currently made available in the repository to the public either at the finest granularity level (e.g. as a list of results of all individual tests), or in a very high level human- readable format. This document uses ALTO protocol to provide access to large-scale network measurement results, flexible enough to enable querying of specific and possibly aggregated data. "Network Topology data retrieval using ALTO protocol", Hanshu Hong, Cheng Zhou, Chongfeng Xie, Qiufang Ma, 2021-06-24, RFC8345 introduces an abstract YANG data model to represent network topologies. This document uses ALTO protocol to provide access to network Topology data such as L3 topology data , data center network topology data, flexible enough to enable querying of specific and possibly aggregated data. "Tactile Internet Service Requirements", Chathura Sarathchandra, Morteza Kheirkhah, Mona Ghassemian, 2021-07-12, The Tactile Internet refers to a new communication paradigm, which can provide low-latency, reliable and secure transmission for real- time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality, and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and use cases; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. "Multi Distribution master", haisheng yu, 2021-06-27, 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. "Separation Protocol of Locator and Identifier Towards IPv6", haisheng yu, 2021-06-27, In the current TCP/IP architecture, the IPv6 address has a dual meaning in semantics. It not only represents the topological location of the network node, but also the identity of the node, which is usually referred to as the semantic overload problem of the IP address. The semantically overloaded IP address represents the topological position of the network, and the topological position of the network generally does not move, so the device entering the new network environment needs to replace the new identity IP to adapt to the change of the topological position. The semantic overload of IP addresses is not conducive to supporting mobility and user identity authentication, resulting in tight storage space for routing equipment, lack of unified communication identification for network equipment, and difficulties in network traceability and management. In order to solve the problem of IP address semantic overload, this project focuses on the separation technology SPLIT6 of IP address identity and location. "Autonomic IP Address To Access Control Groups Mapping", Yizhou Li, Li Shen, Yujing Zhou, 2021-10-20, This document defines the autonomic technical objectives for IP address/prefix to access control groups mapping. The objectives defined can be used in Generic Autonomic Signaling Protocol (GRASP) to make the policy enforcement point receive IP address and its tied access control groups information directly from the access authentication points and then execute the group based policies. "Semantic Addressing and Routing for Future Networks (SARNET-21) Workshop Report", A. Galis, Zhe Lou, 2021-07-26, This document provides an overview of the "Semantic Addressing and Routing for Future Networks" workshop (SARNET-21), which took place on June 10, 2021, in Paris, France and online as part of the IEEE International Conference on High-Performance Switching and Routing. The main goal of the SARNET-21 workshop was to explore, together with the research community, the use cases and network requirements in the domain of semantic addressing and routing, and identify potential research challenges to be tackled in the future. Note that this document is a report on the proceedings of the SARNET-21 workshop compiled by the authors. It captures the views and positions of the workshop participants as expressed during the workshop. "PCE based BIER Procedures and Protocol Extensions", Huanan Li, Aijun Wang, Huaimo Chen, Ran Chen, 2021-10-18, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for supporting the PCE based Bit Index Explicit Replication (BIER) deployment. "Complaint Feedback Loop Address Header", Jan-Philipp Benecke, 2021-07-08, This document describes a method to allow a mail sender to specify a complaint feedback loop address as an email header and how a mail receiver can use it. This document also 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 a complaint feedback loop address to mailbox providers. Currently, providing and maintaining such an address is a manual to a time-consuming process for mail senders and mailbox providers. "Router Terminology: Functions and Paths", Ron Bonica, 2021-06-29, This document distinguishes between the terms "function" and "path". It also recommends against use of the terms "fast path", "slow path", and "host path" in IETF documents. However, it defines the terms "congestion vulnerable path" and "congestion critical path". "Automatic Commissioning of New Signers: Solving the DNSSEC Bootstrapping Problem using Authenticated Signals from the Zone's Operator", Peter Thomassen, Nils Wisiol, 2021-09-23, This document describes an authenticated in-band method for automatic signaling of a Child DNS zone's delegation signer information from the zone's DNS operator(s). The zone's registrar or registry may subsequently use this signal for automatic DS record provisioning in the parent zone. The protocol is particularly useful in case of managed DNS providers hosting registrant's domains, where DS provisioning has so far been cumbersome. The signaling channel is not specific to the DS bootstrapping use case, but equally suitable for announcing other zone-specific information from the DNS Operator in an authenticated fashion. Further potential applications thus include, for example, key exchange between parties in an [RFC8901] multisigner setup. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on at https://github.com/desec-io/draft-thomassen- dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft- thomassen-dnsop-dnssec-bootstrapping/). The most recent version of the document, open issues, etc. should all be available there. The authors gratefully accept pull requests. ] "Setting Up A special day for the IETF outreach", Jiankang Yao, 2021-07-01, Outreach is very important for IETF's development. This document suggests to set up a special day for the IETF outreach. This day can be used to propaganda the Internet standards, promote their deployment, and attract more new IETFers to join IETF to contribute to the Internet. This day can be called Internet Standards Day. "CDNI Metadata Model Extensions", Glenn Goldstein, Will Power, Guillaume Bichot, Alfonso Siloniz, 2021-07-02, 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 proposed extensions to the [RFC8006] Medadata Model by way of a set of GenericMetadata objects that address extend the original CDNI capabilites to meet the more general needs of the CDN and Open Caching industry. "Problems and Requirements of Satellite Constellation for Internet", Lin Han, Richard Li, 2021-10-19, 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. "A Voucher Artifact for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, 2021-07-04, This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", Brian Carpenter, Stuart Cheshire, Robert Hinden, 2021-08-17, 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 specification (RFC 3986) accordingly, and obsoletes RFC 6874. "IS-IS and OSPF Extension for Event Notification", Peter Psenak, Les Ginsberg, Ketan Talaulikar, 2021-07-05, Link-state protocols like IS-IS and OSPF have been designed to distribute state information - state of the local adjacencies, state of the local prefix reachability, etc. Each state can have additional attributes associated with it, but all the attributes are only meaningful while the state exists. This document extends link-state IGPs to distribute event notifications. An event notification has a very limited lifetime. It is rapidly propagated across the network and leaves no state after its lifetime. "CDNI Capacity Insights Capability Advertisment Extensions", Andrew Ryan, Ben Rosenblum, Nir Sopher, 2021-07-05, 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 and CDNI Metadata Objects in RFC 8006. The defined Capability Objects structure and interface for advertisments and managment of a downstream CDN capacity. "Applications Multiplexing a QUIC Session", Jiao Kang, liangqiandeng, Peng Liu, 2021-07-05, 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. "NICER - a better usage profile on ICE", Jonas Oreland, Harald Alvestrand, 2021-07-06, NICER presents an usage profile of ICE that permits more dynamic adaptation to network conditions over the time of a call. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (dispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dispatch/. Source for this draft and an issue tracker can be found at https://github.com/alvestrand/nicer-spec. "An Autonomic Mechanism for Resource-based Network Services Auto-deployment", Joanna Dang, Sheng Jiang, Zongpeng Du, Yujing Zhou, 2021-10-09, This document specifies an autonomic mechanism for resource-based network services deployment through the Autonomic Control Plane (ACP) in an Autonomic Network. This mechanism uses the GRASP in [RFC8990] to exchange the information among the autonomic nodes so that the resource among the service path can be coordinated. "Compressed SRv6 Segment List Encoding in SRH", Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Bruno Decraene, Dezhong Cai, Dan Voyer, Francois Clad, Shay Zadok, Jim Guichard, Liu Aihua, Robert Raszuk, Cheng Li, 2021-07-28, This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. "Supporting leaves without northbound neighbors connecting to a fat-tree network using RIFT", Zheng Zhang, Yuehua Wei, BenChong Xu, 2021-07-07, 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. "One-way Delay Measurement Based on Deterministic Networking", Yang Li, Hongwei Yang, Tao Sun, 2021-07-07, One-way delay is a key indicator to measure network quality. Some applications are one-way transmission in the network, such as some high-definition video services, and are very sensitive to one-way delay. Excessive delay will affect user experience greatly. To some extent, the network can't even be used, so it is very important to accurately measure the network transmission delay. The current one- way delay measurement method has problems such as high complexity and low measurement accuracy. In order to solve the problem of high- precision one-way delay measurement, a one-way delay measurement method based on deterministic networking is proposed in this document. The method takes advantage of the delay characteristics of the deterministic networking and does not depend on precise time synchronization. "BGP Dissemination of FlowSpec for Transport Aware Mobility", Linda Dunbar, Kausik Majumdar, Uma Chunduri, 2021-07-10, 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]. "iCalendar: Representing fractional seconds in iCalendar", Neil Jenkins, Robert Stepanek, Michael Douglass, 2021-07-07, This document defines a way to represent fractional seconds in iCalendar. "Verification of Routes Using Region Authorization", Chen Shen, Wenyan Yu, Yisong Liu, Haibo Wang, Shuanglong Chen, 2021-07-07, 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, 2021-07-08, 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. "Secure EVPN MAC Signaling", Pascal Thubert, Tony Przygienda, Jeff Tantsura, 2021-07-08, This specification adds attributes to EVPN to carry IPv6 address metadata learned from RFC 8505 and RFC 8928 so as to maintain a synchronized copy of the 6LoWPAN ND registrar at each EVPN router and perform locally a unicast IPv6 ND service for address lookup and duplicate address detection. "Generic Metric for the AIGP attribute", Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, 2021-07-26, 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, 2021-07-08, [RFC9012] 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, and 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). "VEGA: A Genetic Method for Planning Virtual Network Embedding Configurations", Pedro Martinez-Julia, Diego Lopez, 2021-07-08, The number of elements composing virtual networks (VN), together with the number of elements in the substrate networks (SN), makes unfeasible to obtain in a short time an optimum configuration for the assignation of elements from the VN to the SN. Here we present VEGA, standing for Virtual network Embedding method based on a Genetic Algorithm. It defines a particular strategy and heuristic to provide configurations for network embedding that are close to the optimum in a short time. "IGMP/MLD Extension for Multicast Source Management", Huanan Li, Aijun Wang, 2021-07-09, This document describes extensions to Internet Group Management Protocol(IGMP) and Multicast Listener Discover(MLD) protocols for supporting interaction between multicast sources and routers, accomplishing multicast source management. "Problem Statement and Requirement for Inband Flow Learning", Liuyan Han, Minxue Wang, Fan Yang, Jinming Huang, 2021-07-09, Alternate-Marking (coloring) provides a method to perform packet loss, delay, and jitter measurements on live traffic. At the same time, on-path telemetry techniques are used to enable the collection and correlation of performance information to further support autonomous network operations. However, network operators still face the challenge of inband flow identification in large scale deployment. This document addresses the problems by introducing the real network scenarios, and proposes the requirements of supporting inband flow learning of flow information telemetry. "YANG Data Model for FlexE Management", Minxue Wang, Liuyan Han, Yuanlong Jiang, 2021-07-09, This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE groups. It also supports the configuration of each FlexE client as an interface. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). "An Efficient Data collection method for Digital Twin Network", Yanhong Zhu, Danyang Chen, Cheng Zhou, 2021-07-09, Digital Twin Network (DTN) is a network system with Physical Network and Twin Network, which can be mapped interactively in real time. The construction of Digital Twin Network requires real-time data of Physical Network to update the state of Twin Network. However the existing method collects the full amount of data from the Physical Network for modeling, and does not consider the problems such as insufficient storage resources, low computational efficiency and waste of bandwidth resources. This document introduces an efficient data collection method in which the Twin Network sends instructions to the Physical Network to collect data on demand, and then the Physical Network parses and executes instructions such as data cleaning and knowledge representation, and sends the processed or requested data to the Digital Twin Network. "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil Cook, Mohamed Boucadair, 2021-10-13, 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 defines a mechanism to explain the reason for the DNS filtering and provides HTTPS URIs to get more detail. This information can be parsed by the client and displayed, logged, or used for other purposes. "S-BFD over SRv6", Zhiqiang Li, Tao Sun, Cheng Wei, Junjie Wang, 2021-07-09, Bidirectional Forwarding Detection (BFD) can be used to monitor paths between node. 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. This draft describes a method to simplify the implementation of S-BFD over SRv6 by using SRH.flag to instruct the S-BFD peer node to do reverse operation of SRv6 SID list. "Involuntary Onwership Transfer of IoT devices: problem statement", Michael Richardson, 2021-07-12, This document details a problem statement relating to ownership of IoT devices. The problem details is that of changing ownership or possession of a device when against the consent or knowledge of the device and/or manufacturer. Examples relating to outer door control are used to illustrate the problem statement in an intuitive scope. "Deprecating Obsolete Key Exchange Methods in TLS", Nimrod Aviram, 2021-07-09, This document deprecates the use of RSA key exchange in TLS, and limits the use of Diffie Hellman key exchange over a finite field such as to avoid known vulnerabilities or improper security properties. "Find Code Related to an Internet-Draft or RFC", Charles Eckel, 2021-07-09, Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and to find such code. "SRv6 inter-domain mapping SIDs", Salih A, Shraddha Hegde, Rejesh Shetty, Ron Bonica, 2021-07-10, This document describes three new SRv6 end point behaviors, named END.REPLACE, END.REPLACEB6 and END.DB6. These SIDs are used in distributed inter-domain solutions for connecting SRv6 domains. This behavior is normally executed on border routers between different domains. These SIDs can also be used to provide multiple intent based paths across these domains. "Transmission of SCHC-compressed packets over IEEE 802.15.4 networks", Carles Gomez, Ana Minaburo, 2021-07-10, 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. "Multi Codec RTP payload format", Sergio Murillo, Youenn Fablet, Alex Gouaillard, Justin Uberti, 2021-07-11, RTP Media Chains usually rely on piping encoder output directly to packetizers. Media packetization formats often support a specific codec format and optimize RTP packets generation accordingly. With the development of Selective Forward Unit (SFU) solutions, RTP Media Chains used in WebRTC solutions are increasingly relying on application-specific transforms that sit between encoder and packetizer on one end and between depacketizer and decoder on the other end. These transforms are typically encrypting media content so that the media content is not readable from the SFU, for instance using [SFrame] or [WebRTCInsertableStreams]. In that context, RTP packetizers can no longer expect to use packetization formats that mandate media content to be in a specific codec format. This document provides a solution to that problem by describing a RTP packetization format that can be used for many media content, and how to negotiate use of this format. This document also describes a solution to allow SFUs to continue performing packet routing on top of this RTP packetization format. "Computing Delivery in Routing Network", Daniel Huang, Bin Tan, Peng Liu, 2021-07-11, This document drafts a proposal of Computing Delivery in Routing Network which incorporates both computing and networking metrics into the routing polices and enables the network sensing and scheduling computing services based upon traditional networking services. A mechanism of two-class computing power granularity and two segment forwarding is illustrated for end-to-end networking and computing service in the cloud sites, while major networking and computing actors is defined in terms of functionality. An example work flow is demonstrated, and both control plane and data plane solution consideration is proposed. "Empty Non-Terminal Sentinel for Black Lies", Shumon Huque, 2021-07-27, The Black Lies method of providing compact DNSSEC denial of existence proofs has some operational implications. Depending on the specific implementation, it may provide no way to reliably distinguish Empty Non-Terminal names from names that actually do not exist. This draft describes the use of a synthetic DNS resource record type to act as an explicit signal for Empty Non-Terminal names and which is conveyed in an NSEC type bitmap. "Security for the NFSv4 Protocols", David Noveck, 2021-10-13, 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 the RPC transport. This preliminary 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 a successor 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. "Computing-aware Networking Use case of ALTO", Peng Liu, Yuexia Fu, 2021-07-11, The ever-emerging new services are imposing more and more highly demanding requirements on the network. In order to meet these requirements, some new technology trends of network emerge as the times require. On the one hand, for the selection of service node and forwarding path, in addition to considering the network topology and link state, more factors are also considered, such as the computing properties of service node; On the other hand, network and application present the trend of mutual perception, including application to perceive the state of network path, or network to perceive the demand of application. This draft describes a new network scenario and architecture considering computational properties, and assumes that Alto could be used as an important node to realize the deployment of services, and to assist in the selection of service nodes. "BGP for BIER-TE Path", Huaimo Chen, Mike McBride, Ran Chen, Gyan Mishra, Aijun Wang, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2021-07-12, This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path. "PCE for BIER-TE Ingress Protection", Huaimo Chen, Mike McBride, Gyan Mishra, Yisong Liu, Aijun Wang, Lei Liu, Xufeng Liu, 2021-07-11, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for protecting the ingress of a BIER-TE path. "EVPN multi-homing support for L3 services", Michael MacKenzie, Patrice Brissette, Satoru Matsushima, 2021-07-11, 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. "Generic HTTP Binding for WebTransport using QUIC", Martin Thomson, 2021-07-11, The WebTransport API provides an interface to HTTP resources that provides transport-layer capabilities. This document describes how a subset of the QUIC protocol can be used to provide these transport capabilities. "Encoding Network Slice Identification for SRv6", Weiqiang Cheng, Liyan Gong, Changwang Lin, 2021-07-12, This document describe a method to encode network slicing identifier within SRv6 domain. "YANG Data Model for Topology Filter", Vishnu Beeram, Tarek Saad, 2021-07-12, This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. "Requirements of applying path-aware networking for dynamic path selection", Yuexia Fu, Peng Liu, 2021-07-12, Emerging new services have new business characteristics, different from traditional C/S business model, whose most traffic is downstream traffic, more and more new business with gradually increasing upstream traffic have appeared, such as short videos, live sales etc, . Due to the new traffic characteristics of these services, more requirements have been put forward for the choice of network paths. In addition, emerging services also put forward new requirements for computing. Only selecting the network path or the service node cannot meet the stringent requirements. The perception of network paths and path selection also need to consider the characteristics of the service, and further need to coordinate the state of the network side and the service node side. The application of path-aware networking can assist the terminal to better perceive the network status, and also combine the status of the service node to achieve on-demand, more fine-grained path selection. "Considerations on Application - Network Collaboration Using Path Signals", Jari Arkko, Ted Hardie, Tommy Pauly, 2021-07-12, Encryption and other security mechanisms are on the rise on all layers of the stack, protecting user data and making network operations more secured. Further, encryption is also a tool to address ossification that has been observed on various layers of the stack over time. Separation of functions into layers and enforcement of layer boundaries based on encryption supports selected exposure to those entities that are addressed by a function on a certain layer. A clear separation supports innovation and also enables new opportunities for collaborative functions. RFC 8558 describes path signals as messages to or from on-path elements. This document states principles for designing mechanisms that use or provide path signals and calls for actions on specific valuable cases. "Services Deployment Guideline in DetNet Network", Joanna Dang, Zongpeng Du, Yizhou Li, 2021-10-09, Deterministic Networking (DetNet) defined in [RFC8655] provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. DetNet network administrators worldwide can deploy DetNet services into their networks. This document aims to provide a guideline for DetNet network administrators. "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition", Ori Finkelman, Sanjay Mishra, Nir Sopher, 2021-07-28, 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. "OSCORE-capable Proxies", Marco Tiloca, Rikard Hoeglund, 2021-07-12, 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 OSCORE is used to protect CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Besides, it defines how a CoAP message can be double-protected through "OSCORE-in-OSCORE", i.e., 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 applies to Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. "Design Consideration of IPv6 Multicast Source Routing (MSR6)", Weiqiang Cheng, Gyan Mishra, Zhenbin Li, Aijun Wang, Zhuangzhuang Qin, Chi Fan, 2021-07-12, This document discusses the design consideration of IPv6 source routing multicast solution. "SDP Security Descriptions is NOT RECOMMENDED and Historic", John Mattsson, Magnus Westerlund, 2021-07-12, Key exchange without forward secrecy enables pervasive monitoring. Massive pervasive monitoring attacks relying on key exchange without forward secrecy have been reported, and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to long-term keys enable passive attackers to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Session Description Protocol (SDP) Security Descriptions (RFC 4568) does not offer PFS and has a large number of additional significant security weaknesses. This document specifies that use of the SDP Security Descriptions is NOT RECOMMENDED. New deployments SHOULD forbid support of SDP Security Descriptions. This document reclassifies RFC 4568 (SDP Security Descriptions) to Historic Status and also obsoletes RFC 4568. This document updates RFC 7201 (Options for Securing RTP Sessions) to note that SDP Security Descriptions SHOULD NOT be used. "Gap Analysis of IPv6 Multicast Source Routing (MSR6)", Zhenbin Li, Gyan Mishra, Zhuangzhuang Qin, 2021-07-12, This document analyses the gaps of the existing IPv6 multicast solutions under discussion in IETF based on the requirements. "Gap Analysis in Internet Addressing", Yihao Jia, Dirk Trossen, Luigi Iannone, Nirmala Shenoy, Paulo Mendes, 2021-07-12, There exist many extensions to Internet addressing, as it is defined in [RFC0791] for IPv4 and [RFC8200] for IPv6, respectively. Those extensions have been developed to fill gaps in 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 fill the gap together with examples of solutions doing so. While introducing such extensions, we outline the issues we see with those extensions. This ultimately leads to consider whether or not a more consistent approach to tackling the identified gaps, beyond point-wise extensions as done so far, would be beneficial. The benefits are the ones detailed in the companion document [I-D.jia-intarea-scenarios-problems-addressing], where, leveraging on the gaps identified in this memo and scenarios provided in [I-D.jia-intarea-scenarios-problems-addressing], a clear problem statement is provided. "RTP over QUIC", Joerg Ott, Mathis Engelbart, 2021-07-12, 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. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/mengelbart/rtp-over-quic-draft. "Service Function Chaining (SFC) Parallelism and Diversions", Donald Eastlake, 2021-07-29, 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, 2021-10-13, 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. "A Yang Data Model for Operations, Administration, and Maintenance of ALTO Protocol", Jingxuan Zhang, Dhruv Dhody, Kai Gao, 2021-07-12, This document defines a YANG data model for the operations and 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. "Flowspec TTL (Time to Live) Match", Philippe BERGEON, 2021-07-12, This document defines a new component type to match TTL (Time to Live) values using BGP Flow Specification rules. "Multi-tenant Data Center Use Case for IPsec Load Balancing", Paul Bottorff, 2021-07-12, IPsec is of increasing importance within data centers to secure tunnels used to carry multi-tenant traffic encapsulated using the Network Virtualization over L3 (NVO3) protocols. Encrypting NVO3 tunnels provides defense against bad actors within the physical underlay network from monitoring or injecting overlay traffic from outside the NVO3 infrastructure. When securing data center tunnels using IPsec it becomes crucial to retain entropy within the outer IPsec packet headers to facilitate load balancing over the highly meshed networks used in these environments. While entropy is necessary to support load distribution algorithms it is also important that the entropy codes used retain integrity of flows to prevent performance deterioration resulting from packet re-ordering. Here, we describe a use case for load balancing IPsec traffic within multi-tenant data centers. "ACH6 in Segment Routing", Fan Yang, Tianran Zhou, 2021-07-12, Associated Channel over IPv6 (ACH6) provides a control channel to one specific IPv6 forwarding path for control and management purpose. When ACH6 is used in a Segment Routing network, it provides a control channel to an SRv6 path. This document specifies an SRv6 ACH6 mechanism and describes how ACH6 is applied in a Segment Routing network. "ACH6 for OAM in Segment Routing", Fan Yang, Tianran Zhou, Yali Wang, 2021-07-12, This document defines an OAM toolset encapsulated in ACH6 to provide the functions of performance measurement, continuity check and verification to an SRv6 path. "Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop Deployments", XiPeng Xiao, Eduard Metz, Gyan Mishra, 2021-07-12, Neighbor Discovery (ND) is an integral part of IPv6 first-hop. Due to limitation of certain L2 media's support to ND, a number of issues can happen in certain scenarios. The corresponding solutions for these issues have also been designed. These issues and solutions are summarized in RFC3756, RFC6583, OPSECv27. However, there is no guideline on how to avoid the issues or how to select the proper solutions. This document analyzes existing solutions and summarizes the wisdoms embedded in these solutions into an insight: isolating hosts in L2 and L3 can be effective in preventing ND issues. In deployment scenarios where the ND issues can occur, this prevention approach can be more effective than deploying various solutions to solve the issues. Based on this insight, a set of guidelines is proposed for future ND deployments. These guidelines describe where and when to isolate hosts in L2 and L3 to prevent ND issues, and how to select suitable solutions for the remaining issues. This will likely simplify ND deployments. The impact of the guidelines to other components of IPv6 first-hop is also analyzed and appears small. Therefore, the guidelines will likely simplify the overall IPv6 first-hop deployments. "EAP Usability", Alan DeKok, 2021-07-12, This document defines methods which enable simpler deployment of TLS- based EAP methods. It defines new certificate fields, and uses existing certificate fields in order describe new methods for bootstrapping security. The methods defined here change TLS-based EAP supplicant configuration from a complex and insecure process to one that is automated, and is essentially trivial. These methods are still, however, compatible with existing standards and practices. "Flex Algo Extension for 5G Edge Computing Service", Linda Dunbar, Huaimo Chen, Aijun Wang, 2021-10-11, Routers in 5G Local Data Network (LDN) can use additional site-costs, preference, and other application related metrics on top of the network condition to compute constraint-based SPF within the 5G LDN to enhance performance for selected services. This draft describes those application server related metrics to be used in Flexible Algorithms. "IP Address Privacy Considerations", Matthew Finkel, Luigi Iannone, 2021-07-26, This document provides an overview of privacy considerations related to user IP addresses. It includes an analysis of some current use cases for tracking of user IP addresses, mainly in the context of anti-abuse. It discusses the privacy issues associated with such tracking and provides input on mechanisms to improve the privacy of this existing model. It then captures requirements for proposed 'replacement signals' for IP addresses from this analysis. In addition, existing and under-development techniques are evaluated for fulfilling these requirements. "DNS over HTTPS via HTTP proxies", Kazunori Fujiwara, 2021-07-12, DNS queries over HTTPS (DoH) hides DNS query information by (HTTPS) encryption. However, DoH providers know both query source IP addresses and DNS queries, and it is a privacy issue of DoH. It is possible to hide query source IP addresses from DoH providers by existing protocol (HTTP) and implementations (HTTP proxy software). This document proposes the use of DoH via HTTP proxy services. "RUSH - Reliable (unreliable) streaming protocol", Kirill Pugin, Alan Frindell, Jordi Cenzano, Jake Weissman, 2021-07-12, RUSH is an application-level protocol for ingesting live video. This document describes core of the protocol and how it maps onto QUIC Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/afrind/draft-rush. "Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS Networks", Rakesh Gandhi, Patrice Brissette, Eddie Leyton, 2021-07-12, 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. "A YANG Data Model for Network Resource Reservation Manager", Tarek Saad, Vishnu Beeram, Xufeng Liu, 2021-07-12, This document defines a YANG data model for the network Resource Reservation Manager (RRM). The RRM can be deployed to manage set of network resources scoped to a node, a region of a network, a domain of the network, or globally for all resources in a network. This model covers data for configuration, operational state, remote procedural calls pertaining to links managed by the RRM. "Functional Addressing (FA) for internets with Independent Network Address Spaces (IINAS)", Toerless Eckert, 2021-07-12, Recent work has raised interest in exploring network layer addressing that is more flexible than fixed-length addressing as used in IPv4 (32 bit) and IPv6 (128 bit). The reasons for the interest include both support for multiple and potentially novel address semantics, but also optimizations of addressing for existing semantics such as unicast tailored not for the global Internet but to better support private networks / limited domains. This memo explores in the view of the author yet little explored reasons for more flexible addresses namely the problems and opportunities for Internetworking with Independent Network Address Spaces (IINAS). To better enable such internetworks, this memo proposes a framework for a Functional Addressing model. This model also intends to support several other addressing goals including programmability and multiple semantics. "Mapping between YANG and SDF", Jana Kiesewalter, Carsten Bormann, 2021-07-12, YANG and SDF are two languages for modelling the interaction with and the data interchanged with devices in the network. As their areas of application (network management, IoT, resp.) overlap, it is useful to be able to translate between the two. The present specification provides information about how models in one of the two languages can be translated into the other. This specification is not intended to be normative, but to help with creating translators. "Problems with existing DetNet bounded latency queuing mechanisms", Toerless Eckert, Stewart Bryant, 2021-07-12, The purpose of this memo is to explain the challenges and limitations of existing (standardized) bounded latency queuing mechanisms for desirable (large scale) MPLS and/or IP based networks to allow them to support DetNet services. These challenges relate to low-cost, high-speed hardware implementations, desirable network design approaches, system complexity, reliability, scalability, cost of signaling, performance and jitter experience for the DetNet applications. Many of these problems are rooted in the use of per- hop, per-flow (DetNet) forwarding and queuing state, but highly accurate network wide time synchronization can be another challenge for some networks. This memo does not intend to propose a specific queuing solution, but in the same way in which it describes the challenges of mechanisms, it reviews how those problem are addressed by currently proposed new queuing mechanisms. "ECDSA Signatures in Verification-Friendly Format", Rene Struik, 2021-07-12, This document specifies how to represent ECDSA signatures so as to facilitate accelerated verification of single signatures and fast batch verification. We demonstrate that this representation technique can be applied retroactively by any device (rather than only by the signer), thereby facilitating transitioning to always generating ECDSA signatures in this way, without changing standardized ECDSA specifications with instantiations with prime- order curves. This facilitates verifying devices to reap the significant speed-up potential (ranging from ~1.3x to ~6x) fast verification techniques afford. "Concise Reference Integrity Manifest", Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan, 2021-07-26, Remote Attestation Procedures (RATS) enable Relying Parties to put trust in the trustworthiness of a remote Attester and therefore to decide if to engage in secure interactions with it - or not. Evidence about trustworthiness can be rather complex, voluminous or Attester-specific. As it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence, that burden is taken on by a Verifier. In order to conduct Evidence appraisal procedures, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers, such as manufacturers, distributors, or 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, 2021-08-06, 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, 2021-07-12, With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite keys, for use with composite signature and encryption data. This document defines the structures CompositePublicKey, CompositePrivateKey, which are sequences of the respective structure for each component algorithm. This document makes no assumptions about what the component algorithms are, provided that they have defined algorithm identifiers. The only requirement imposed by this document is that all algorithms be of the same key usage; i.e. all signature or all encryption. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite signatures and encryption. "Explicit Pairwise Composite Keys For Use In Internet PKI", Mike Ounsworth, Serge Mister, 2021-07-12, With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite public keys and composite signature data. This draft defines a structure generic enough to be useful beyond the post-quantum transition for any situation where a widely-supported but untrusted algorithm is being migrated to newer cryptography. This document defines structures for binding an explicit pair of cryptographic algorithms together into a single object identifier, and it provides ASN.1 structures for encoding these pairwise composite public keys, private keys in wire protocols, as well as using them in conjunction with composite signatures, encryption and key transport mechanisms. "Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements", Thomas Fossati, Yogesh Deshpande, Henk Birkholz, 2021-07-12, PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. "Composite Encryption For Use In Internet PKI", Mike Ounsworth, John Gray, Serge Mister, 2021-07-12, With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite encryption data. This document defines a content encryption process following the hybrid model as described in the NIST Post-Quantum Crypto FAQ. This draft defines three composite encryption modes. First, Composite Key Transport using Encryption primitives which encrypts a message (typically a content encryption key) for a recipient with a composite public key composed entirely of encryption keys by encrypting it with multiple one-time-pad keys, each encrypted under a different recipient public key. Second, Composite Key Transport using Encryption and KEM primitives is the generalization of the previous mode to support a mixture of encryption and KEM algorithms. Third, Composite Key Exchange is the most general and supports establishing a shared secret using any combination of encryption, KEM, and key exchange primitives where a master shared secret is generated using NIST SP 800-56Cr2. "Interconnecting Limited Domains Based on Declared Communication Requirements", Carsten Bormann, 2021-07-12, "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, 2021-07-12, 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. "ALTO Transport using HTTP/2", Y. Yang, 2021-07-12, The ALTO base protocol and ALTO/SSE are based on HTTP/1.x, and they introduce complexities to address limitations of HTTP/1.x. The deployment of HTTP/2 allows this document to design ALTO/H2, which benefits from the additional capabilities of HTTP/2 to provide services for ALTO. "Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet, Michael Behringer, 2021-07-12, 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. "Host Extensions IP Multicasting - Any Source Multicast (ASM)", Robert Hinden, Toerless Eckert, 2021-07-12, This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support Any Source Multicast (ASM) IP Multicasting or abbreviated IP Multicast. Distribution of this memo is unlimited. "Virtual Orchestra Usecase and Research Challenges", Kiran Makhijani, Lijun Dong, 2021-07-12, This document describes open research challenges for emerging media- oriented ensemble applications. One such driving scenario is the network delivery of virtual orchestra that imposes multi-disciplinary challenges. Specifically, of interest are the group communication patterns in the production, delivery and consumption as different dimensions relating to the communication networks. This document brings forth current research and engineering challenges in immersive media ensembles. The network domain problems come down to the specification of coordination of the received content with dependency constraints. The challenges depict both real and quasi- realtime behavior. A number of endpoint actors get involved in delivering the ensemble aspect, the research challenges also describe the expectations from the end points. "ALTO Uses Cases for Cellular Networks", Gang Li, Sabine Randriamasy, Chunshan Xiong, 2021-07-12, This draft presents a number of use cases of applications running on endpoints located in cellular networks and whose performances highly depend on network information. This document first, shows how the performances of these applications can be further improved with ALTO provided abstracted network information and transportation means thereof. Second, upon reviewing the existing ALTO capabilities, it lists the ALTO features that need to be extended or defined to support the presented use cases. "A summary of security-enabling technologies for IoT devices", Brendan Moran, 2021-07-12, The IETF regularly develops new technologies. Sometimes there are several standards that can be combined to become vastly more than the sum of their parts. Right now, there are six technologies either recently adopted or poised for adoption that create such a cluster. Combining secure onboarding, remote attestation, secure update, software bill-of-materials/expected attestation, automated network policy enforcement, and trusted execution environment provisioning, devices can be defended from many threats. This is an opportunity for an inflection point for more secure and trustworthy devices. Simultaneous adoption of two or more of these six standards could create the foundation of computing devices that are worth trusting. "HTTP Datagram Prioritization", Lucas Pardue, 2021-07-26, Application protocols using the QUIC transport protocol rely on streams, and optionally the DATAGRAM extension, to carry application data. Streams and datagrams can be multiplexed but QUIC provides no interoperable prioritization scheme or signaling mechanism itself. The HTTP Extensible Prioritization scheme describes how to prioritize streams in HTTP/2 and HTTP/3. This document adopts the scheme to support HTTP datagrams. "Transient Hiding of Hop-by-Hop Options", Donald Eastlake, 2021-10-18, There are increasing requests for a variety IPv6 hop-by-hop options but such IPv6 options and all IPv4 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. "Internet Threat Model Guidance", Jari Arkko, Stephen Farrell, 2021-07-12, 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. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood. "BGP Peer Auto-Configuration", Jeyananth Jeganathan, Venkata Avula, 2021-07-12, This document describes a layer 3 protocol (Service advertisement) to help bgp to advertise service availability and local configurations . This enable bgp speakers to discover bgp peers transport endpoints and peer's configuration within link. With Service advertisement, receivers could successfully bring up bgp protocol session without mundane configurations. "KEM-based Authentication for TLS 1.3", Sofia Celi, Peter Schwabe, Douglas Stebila, Nick Sullivan, Thom Wiggers, 2021-07-12, This document gives a construction for KEM-based authentication in TLS 1.3. The overall design approach is a simple: usage of Key Encapsulation Mechanisms (KEM) for certificate-based authentication. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/claucece/draft-celi-wiggers-tls-authkem. "MPLS Data Plane Encapsulation for In-situ OAM Data", Rakesh Gandhi, Zafar Ali, Frank Brockners, Bin Wen, Bruno Decraene, Voitek Kozak, 2021-09-09, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two nodes in the network. This document defines how IOAM data fields are transported with MPLS data plane encapsulation using new Generic Associated Channel (G-ACh). "Automatic Replication of DNS-SD Service Registration Protocol Zones", Ted Lemon, 2021-07-26, 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, 2021-07-26, 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). "Permissionless Advertising and Discovery of DNS-SD Authoritative Zones", Ted Lemon, Deng Yu, 2021-07-26, This document describes how to make DNS-SD browsing domains available for browsing and discovery without requiring special cooperation from the network infrastructure. Zones made available in this way are browsed using DNS or DNS Push. The mechanism for advertising them is Multicast DNS (mDNS). This allows DNS-SD browsers to benefit from the permissionless aspects of mDNS without relying on mDNS for all queries, which improves scalability and reliability in applications where many services may be advertised. "Different aspects of onboarding for IoT/Edge Devices", Erik Nordmark, 2021-07-26, Previous onboarding discussions have focused on network onboarding. In this note we put that in the context of the larger onboarding picture to also discuss the onboarding to some management or orchestration system. "Tunnelling SRT over QUIC", Maxim Sharabayko, Maria Sharabayko, 2021-07-28, This document presents an approach to tunnelling SRT live streams over QUIC datagrams. QUIC [RFC9000] is a UDP-based transport protocol providing TLS encryption, stream multiplexing, and connection migration. It was designed to become a faster alternative to the TCP protocol [RFC7323]. An Unreliable Datagram Extension to QUIC [QUIC-DATAGRAM] adds support for sending and receiving unreliable datagrams over a QUIC connection, but transfers the responsibility for multiplexing different kinds of datagrams, or flows of datagrams, to an application protocol. SRT [SRTRFC] is a UDP-based transport protocol. Essentially, it can operate over any unreliable datagram transport. SRT provides loss recovery and stream multiplexing mechanisms. In its live streaming configuration SRT provides an end-to-end latency-aware mechanism for packet loss recovery. If SRT fails to recover a packet loss within a specified latency, then the packet is dropped to avoid blocking playback of further packets. The Datagram Extension to QUIC could be used as an underlying transport instead of UDP. This way QUIC would provide TLS-level security, connection migration, and potentially multi-path support. It would be easier for existing network facilities to process, route, and load balance the unified QUIC traffic. SRT on its side would provide end-to-end latency tracking and latency-aware loss recovery. "BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu, 2021-07-29, 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. "LISP Based Multi-AS Backbone Federation", Victor Moreno, 2021-07-29, As multiple organizations interconnect their networks through peering agreements, it is desirable to preserve the services enabled by a LISP overlay over such interconnection of independent networks. This specification documents the requirements imposed by the deployment scenario in which multiple organizations federate their backbones with the objective of running a LISP overlay to enable services such as mobility or VPNs. The requirements for policies, enforcement and authoritative control of network assets are captured from the perspective of the operator. "Deprecate Use of 1024-bit Diffie-Hellman Moduli in Public Key Cryptography for Initial Authentication in Kerberos", Robbie Harwood, 2021-08-06, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) permits a client and a Kerberos Domain Controller (KDC) to use a Diffie-Hellman (DH) exchange to derive an encryption key. The group with minimum modulus size permitted for this exchange is 1024 bits, which recent security research has shown to provide insufficient protection against organizations with sufficient computing resources, such as state-sponsored actors. This document updates RFC 4556 to increase the minimum group size to 2048 bits and define permitted groups of size larger than 4096-bits. "Egress Protection for EVPN BUM", Yubao Wang, Ran Chen, 2021-07-30, When the procedures per [I-D.ietf-rtgwg-srv6-egress-protection] are applied to EVPN services, the egress-protection on PLR is typically more faster than the new DF node of the affected ESI is re-elected. As a result of that, replicated BUM packets will be sent to the CEs of the affected ES. This draft describes a "NDF-bias" mechanism that is used to avoid such excessive BUM packets. "DTLS for UDP-notif", Alex Feng, Pierre Francois, Tianran Zhou, Marco Tollini, 2021-07-30, This document describes a DTLS layer for the UDP-notif protocol. DTLS allows a server and a client to exchange secured messages over UDP. This transport layer permits networking devices to send secured UDP-notif messages over the network. "Deprecating FFDH Ciphersuites in TLS", Carrick Bartle, Nimrod Aviram, Filippo Valsorda, 2021-07-30, This document deprecates the use of finite field Diffie Hellman cipher suites and discourages the use of elliptic curve Diffie Hellman cipher suites, both of which have known vulnerabilities or improper security properties when implemented incorrectly. "Advertisement of Stub Link Attributes", Aijun Wang, Zhibo Hu, Gyan Mishra, Acee Lindem, Jinsong Sun, 2021-09-21, This document describes the mechanism that can be used to differentiate the stub links from the normal interfaces within ISIS or OSPF domain. "Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?", Alfred Morton, 2021-09-06, This memo addresses the problem of defining relevant properties and metrics with the goal of improving Internet access for all users. Where the fundamental metrics are well-defined, a framework to standardize new metrics exists and been used with success. Users consider reliability to be important, as well as latency and capacity; it really depends who you ask and their current experiences. "MTU propagation over EVPN Overlays", Saumya Dikshit, Vinayak Joshi, A Nayak, 2021-08-03, Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in an 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 underlay routers/switches forming the basis of 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, 2021-08-05, 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, 2021-08-05, 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 Link-State extensions for BIER-TE", Ran Chen, Zheng Zhang, 2021-08-06, Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [I-D.ietf-bier-te-arch]. 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. "Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route", Yubao Wang, 2021-08-26, This draft discusses the issues with several service interfaces of L3 EVIs. Then it proposes an extension to [RFC7432] and [I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP aliasing for Layer 3 routes that is needed for L3-EVIs to build a complete IP ECMP. It also introduced two new EVPN Service Interfaces for EVPN VPLS services and an extension of AC-ID extended community to improve ARP/ND Probing upon remote PE failures. "Authenticated delegation information using DS records", Benjamin Schwartz, 2021-08-19, This draft describes a mechanism for conveying arbitrary authenticated DNS data from a parent nameserver to a recursive resolver as part of a delegation response. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (ds@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ds/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/ds-glue. "License Activation Protocol", Maximilian Lorlacks, 2021-09-13, This document defines an experimental method for uniform license activation mechanism for use in digital rights management (DRM). "Sub-slicing for SRv6", Louis Chan, 2021-08-08, 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. "LISP Support for Dynamic Anycast Routing", Sun Kj, Younghan Kim, 2021-08-09, This draft describes the LISP-based architecture and solutions for supporting dynamic anycast (Dyncast) routing. "DS Algorithms for Securing NS and Glue", Brian Dickson, 2021-09-19, This Internet Draft proposes a mechanism to encode relevant data for NS records on the parental side of a zone cut by encoding them in DS records based on a new DNSKEY algorithm. Since DS records are signed by the parent, this creates a method for validation of the otherwise unsigned delegation records. Notably, support for updating DS records in a parent zone is already present (by necessity) in the Registry-Registrar-Registrant (RRR) provisioning system, EPP. Thus, no changes to the EPP protocol are needed, and no changes to registry database or publication systems upstream of the DNS zones published by top level domains (TLDs). This NS validation mechanism is beneficial if the name server _names_ need to be validated prior to use. "Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)", Greg Mirsky, Jeff Tantsura, Gyan Mishra, 2021-08-12, This document discusses the applicability of Bidirectional Forwarding Detection (BFD) for multipoint networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second Master convergence and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798. "DNS Queries over CoAP (DoC)", Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, 2021-09-01, 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). "Self-Tracing for HTTP", Kazuho Oku, Jana Iyengar, 2021-08-12, This document registers a "Well-Known URI" for exposing state of an HTTP connection to the peer using formats such as qlog schema [QLOG]. "Responsiveness under Working Conditions", Christoph Paasch, Randall Meyer, Stuart Cheshire, Omer Shapira, 2021-08-13, Bufferbloat has been a long-standing problem on the Internet with more than a decade of work on standardizing technical solutions, implementations and testing. However, to this date, bufferbloat is still a very common problem for the end-users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else on the same home-network is watching a 4K movie. The reason for this problem is not the lack of technical solutions, but rather a lack of awareness of the problem-space, and a lack of tooling to accurately measure the problem. We believe that exposing the problem of bufferbloat to the end-user by measuring the end- users' experience at a high level will help to create the necessary awareness. This document is a first attempt at specifying a measurement methodology to evaluate bufferbloat the way common users are experiencing it today, using today's most frequently used protocols and mechanisms to accurately measure the user-experience. We also provide a way to express the bufferbloat as a measure of "Round-trips per minute" (RPM) to have a more intuitive way for the users to understand the notion of bufferbloat. "IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Joseph Salowey, Sean Turner, 2021-08-15, This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document obsoletes RFC8447 and updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301. "The Delivered-To Message Header Field", Viktor Dukhovni, John Levine, 2021-08-16, This document describes the existing usage of the Delivered-To header field in e-mail messages. "TLS ALPN usage in the Session Initiation Protocol (SIP)", Olle Johansson, 2021-08-24, Many SIP specifications use other protocols in addition to the core SIP protocol, like HTTP and MSRP. In order to be able to use multiple protocols on the same port with TLS, a TLS Application Protocol Negotiation Extension (ALPN) protocol ID is needed (RFC 7301 [RFC7301]). This document registers "sip/2" as the ALPN protocol ID for the SIP protocol version 2.0. "Unified representation method of heterogeneous data in industrial Internet", Yaqian Zhang, Shengsheng He, Chen Yp, Wang Zm, H Xia, 2021-08-17, With the advent of 5G era, sensing devices and mobile Internet devices in smart factories are everywhere, and a variety of industrial data from different spatial devices becomes widely available and interwoven. These data are usually generated by streaming, with huge differences in data sources and structures, massive scale, strong correlation and complicated relationship. The great richness of data makes the problem of how to quickly, accurately and deeply dig the hidden value behind the data more complicated than ever. The data generated in different fields are distributed in a variety of business systems, and these data have different structures and forms, so it is difficult to use an efficient form of unified analysis. Based on the data characteristics of heterogeneous data, the multi-source heterogeneous data fusion method is studied based on tensor. "Grant Negotiation and Authorization Protocol", Denis PINKAS, 2021-08-19, This protocol enables an Authorization Server (AS) to issue access tokens to permit an end-user using a client software to perform operations on a protected resource hosted by a Resource Server (RS). These access tokens allow to support capabilities and/or user attributes. The protocol includes means of specifying how the end-user can potentially be involved in an interactive fashion during the process. The client and/or the RS will use these interaction mechanisms to involve the end-user, as necessary, to take decisions. The protocol uses HTTPS for all communications between the client and the AS, as well as between the client and the RS. "Segment-Routing over Forwarding Adjacency Links", Tarek Saad, Vishnu Beeram, Colby Barth, Siva Sivabalan, 2021-08-19, Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) networks can be used to form Forwarding Adjacency (FA) links that carry traffic in those networks. An FA link can be assigned Traffic Engineering (TE) parameters that allow other LSR(s) to include it in their constrained path computation. FA link(s) can be also assigned Segment-Routing (SR) segments that enable the steering of traffic on to the associated FA link(s). The TE and SR attributes of an FA link can be advertised using known protocols that carry link state information. This document elaborates on the usage of FA link(s) and their attributes in SR enabled networks. "The Application Specific Link Attribute (ASLA) Any Application Bit", Shraddha Hegde, Ron Bonica, Chris Bowers, Robert Raszuk, Zhenbin Li, 2021-08-19, 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. "EVPN Mac Dampening Back-off", Saumya Dikshit, Vinayak Joshi, Swathi Shankar, 2021-09-16, 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. "Data Model for Lifecycle Management and Operations", Marisol Palmero, Frank Brockners, Sudhendu Kumar, 2021-08-30, 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, 2021-08-24, 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 reduces the deployment and operational complexities in a network. "RTP Payload Format for the SCIP Codec", Daniel Hanson, MikeFaller, Keith Maver, 2021-08-26, This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP) as audio and video media subtypes. It provides RFC 6838 compliant media Internet-Draft RTP Payload Format for the SCIP Codec August 2021 subtype definitions. SCIP-214.2 and SCIP-210 describe the protocols that comprise the SCIP RTP packet payload. This document follows the registration for related media types called "audio/scip" and "video/scip" with IANA and formatted according to RFC 4855. "Bootstrapping WebSockets with HTTP/3", Ryan Hamilton, 2021-09-01, The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered. This document describes the mechanism for HTTP/3. "I2NSF Application Interface YANG Data Model", Patrick Lingga, Jaehoon Jeong, Yunchul Choi, 2021-08-27, This document describes an information model and a YANG data model for the Application Interface between an Interface to Network Security Functions (I2NSF) Analyzer and Security Controller in an I2NSF system in a Network Functions Virtualization (NFV) environment. The information model and YANG data model is based on the I2NSF Consumer-Facing Interface for enabling feedback delivery based on the information received from the Network Security Function (NSF). "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Claudio Porfiri, 2021-08-27, The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT functions for TCP that allows multiple hosts to reside behind a NAT function and yet share a single IPv4 address, even when two hosts (behind a NAT function) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions needed for the SCTP endpoints and the mechanisms for NAT functions necessary to provide similar features of NAPT in the single point and multipoint traversal scenario. Finally, a YANG module for SCTP NAT is defined. "Providing Instance Affinity in Dyncast", Carsten Bormann, 2021-08-30, Dyncast support in a network provides a client with a fresh optimal path to a service provider instance, where optimality includes both path and service provider characteristics. As a service invocation usually takes more than one packet, dyncast needs to provide instance affinity for each service invocation. Naive implementations of instance affinity require per-application, per service-invocation state in the network. The present short document defines a way to provide instance affinity that does not require, but also does not rule out per-application state. It also discusses how the information that an application needs to operate this mechanism can be provided via the discovery mechanisms offered by a CoRE (Constrained RESTful Environments) server, either in "/.well-known/core" or via the CoRE resource directory. "Antitrust Guidelines for IETF Particiants", Joel Halpern, Brad Biddle, Portia Danley, 2021-08-30, This document provides guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. "The ORIGIN Extension in HTTP/3", Mike Bishop, 2021-09-01, 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. "hashlookup format", Alexandre Dulaunoy, Jean-Louis Huynen, 2021-09-17, 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", Saumya Dikshit, Vinayak Joshi, 2021-09-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 prelimn 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 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]. "JWS Signature Validation Token", Stefan Santesson, Russ Housley, 2021-09-03, This document defines a JSON Web Signature (JWS) profile for the Signature Validation Token defined in [SVT]. "Entitities Involved in the IETF Standards Process", Rich Salz, 2021-10-04, This document describes the individuals and organizations involved in the IETF standards process as described in IETF BCP 9. It includes brief descriptions of the entities involved, and the role they play in the standards process. This document obsoletes RFC 2028. "Protocol extension and mechanism for fused service function chain", Jinyou Dai, Xueshun Wang, Dongping Deng, Xiaoyun Zhang, 2021-09-08, This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. "Deterministic Networking (DetNet) Data Plane - MPLS TC Tagging for Cyclic Queuing and Forwarding (MPLS-TC TCQF)", Toerless Eckert, Stewart Bryant, 2021-09-08, This memo defines the use of the MPLS TC field of MPLS Label Stack Entries (LSE) to support cycle tagging of packets for Multiple Buffer Cyclic Queuing and Forwarding (TCQF). TCQF is a mechanism to support bounded latency forwarding in DetNet network. 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. "SDP Offer/Answer for RTP using QUIC as Transport", Spencer Dawkins, 2021-09-08, This document describes these new SDP "proto" attribute values: "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications that commonly use SDP as a session signaling protocol to set up RTP connections with UDP as its underlying transport protocol, such as SIP and WebRTC. "Updates to Algorithm Related Adjacency SID Advertisement in RF9085", Shaofu Peng, Peter Psenak, 2021-09-10, This draft updates [RFC9085] to defines extensions to the Border Gateway Protocol-Link State (BGP-LS) address family in order to carry algorithm Related Adjacency SID. "Updates to Algorithm Related Adjacency SID Advertisement in RF9085", Ran Chen, Shaofu Peng, Peter Psenak, 2021-09-10, This draft updates [RFC9085] to defines extensions to the Border Gateway Protocol-Link State (BGP-LS) address family in order to carry algorithm Related Adjacency SID. "Traces of EDHOC", Goeran Selander, John Mattsson, 2021-10-20, This document contains some example traces of Ephemeral Diffie- Hellman Over COSE (EDHOC). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (lake@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Source for this draft and an issue tracker can be found at https://github.com/lake-wg/edhoc. "DetNet Bounded Packet-Delay-Variation", Ehsan Mohammadpour, Jean-Yves Le Boudec, 2021-09-10, Some DetNet use-cases (applications) require guaranteed bounds on packet delay-variation, not just on latency. This document gives a methodology to derive guaranteed packet delay-variation bounds in DetNet and apply it to a number of proposed mechanisms. When the required packet delay-variations is very low, clock non-idealities affect the bounds, even in a synchronized DetNet networks. This document also gives a methodology to account for such an effect. "Updates to Anycast Property advertisement for OSPF", Ran Chen, Detao Zhao, Peter Psenak, 2021-09-12, Both SR-MPLS prefixes-SID and IPv4/IPv6 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. This document updates [RFC7684] and [RFC8362], by defining a new flag in OSPFv2 Extended Prefix Opaque LSA [RFC7684] and Prefix Options [RFC8362] to advertise the anycast property, and also updates the corresponding interpretation of the Flags field of the Prefix Attribute Flags TLV in [RFC9085]. "REST API mediatypes", Roberto Polli, 2021-09-15, This document register the following media-types used in APIs on the IANA MEdia Types registry: text/yaml, application/yaml, application/ openapi+json, and application/openapi+yaml "MVPN Inter/Intra-region Tunnel Segmentation", Zhaohui Zhang, 2021-09-15, RFC7524 specifies procedures for Inter-Area Point-to-Multipoint Segmented Label Switched Paths (aka MVPN tunnel segmentation). This document updates RFC7524 by extending the inter-area segmentation concept to inter-region and intra-region segmentation where a region is no longer tied to an IGP area. "Authenticated DNS over TLS to Authoritative Servers", Brian Dickson, 2021-09-20, This Internet Draft proposes a mechanism for DNS resolvers to discover support for TLS transport to authoritative DNS servers, to validate this indication of support, and to authenticate the TLS certificates involved. This requires that the name server _names_ are in a DNSSEC signed zone. This also requires that the delegation of the zone served is protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the keys used for discovery of TLS transport support. Additional recommendations relate to use of various techniques for efficiency and scalability, and new EDNS options to minimize round trips and for signaling between clients and resolvers. "Operating a Glueless DNS Authority Server", Brian Dickson, 2021-09-22, This Internet Draft proposes a method for protecting authority servers against MITM and poisoning attacks, using a domain naming strategy to not require glue A/AAAA records and use of DNSSEC. This technique assumes the use of validating resolvers. MITM and poisoning attacks should only be effective/possible against unsigned domains. However, until all domains are signed, this guidance is relevant, in that it can limit the attack surface of unsigned domains. This guidance should be combined with [I-D.dickson-dnsop-ds-hack] "Framework for QUIC Throughput Testing", Kevin Corre, 2021-09-17, This document adapts the [RFC6349] Framework for TCP Throughput Testing to the [RFC9000] QUIC protocol. The adapted framework describes a practical methodology for measuring end-to-end QUIC Throughput in a managed IP network. The goal of the methodology is to provide a better indication in regard to user experience. In this framework, QUIC, UDP, and IP parameters are specified to optimize QUIC Throughput. "Discovery of Designated Resolvers in the Presence of Legacy Forwarders", Benjamin Schwartz, 2021-09-21, This draft describes how the Discovery of Designated Resolvers (DDR) standard interacts with legacy DNS forwarders, including potential incompatibilities and relevant mitigations. 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. "Network policy to use Network-designated DNS Resolvers", Tirumaleswar Reddy.K, Dan Wing, Kevin Smith, 2021-09-21, This document specifies a mechanism to inform endpoints about any network policy mandating the use of network-designated DNS resolvers. "HTTP Datagram PING", Benjamin Schwartz, 2021-10-04, This draft defines an HTTP Datagram Format Type for measuring the functionality of a Datagram path. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (masque@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/masque/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/h3-datagram-ping. "GRASP Configuration Management Objective", Brian Carpenter, 2021-09-21, This document specifies a technical objective for dynamic configuration of the GeneRic Autonomic Signaling Protocol (GRASP) defined by RFC 8990. "Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension", Aaron Gable, 2021-09-22, This document specifies how an ACME server may provide hints 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. "Extending ICMP for IP-related Information Validation", Liu Yao, 2021-09-22, This document introduces the mechanism to verify the data plane against the control plane in IP/SRv6 networks by extending ICMP messages. "Encapsulation and Processing of Network Slice Selector in IPv6 Data Plane", Weiqiang Cheng, Jiang Wenying, Changwang Lin, 2021-09-29, Packets belong to a network slice need to be forwarded using the specific network resources. A network slice selector is carried in each packet to identify the network slice that it belongs to. This document proposes a new Network Slice Selector Option, and describes the encapsulation and processing of network slice selector in IPv6 data plane using the proposed option. "SDP Offer/Answer for RTP using QUIC as Transport - Design Questions", Spencer Dawkins, 2021-09-29, 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. In writing that document, it became obvious that decisions about an appropriate SDP description would depend on decisions about the way RTP would be encapsulated in QUIC, and different proposals for those encapsulations had made different assumptions. Given that none of these proposals have been adopted by an IETF working group yet, it's not appropriate to try to base a general-purpose set of "QUIC/RTP" IANA registrations on any one of them, so this document includes the questions that have come up, and (as discussions progress) suggested answers for those questions. "BIER with Network Slicing and Flow Differentiation", Zhaohui Zhang, Tony Przygienda, 2021-09-29, This document specifies how BIER works in the context of IETF Network slicing, with or without fined-grained traffic differentiation. "IPv6 Neighbor Discovery Multicast Address Registration", Pascal Thubert, 2021-10-08, This document updates RFC 8505 to enable the address registration of IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550 (RPL) add a new Non-Storing multicast mode and support for anycast addresses. This document also extends RFC 9010 to enable the 6LR to inject the anycast and multicast addresses in RPL. "In Situ OAM Profile for the Linux Kernel Implementation", Tal Mizrahi, Justin Iurman, Frank Brockners, 2021-09-30, In Situ Operations, Administration and Maintenance (IOAM) is used for monitoring network performance and for detecting traffic bottlenecks and anomalies. This document defines an IOAM profile that is used in the Linux kernel implementation, starting from the Linux 5.15 kernel. "Segment Routing in Two Dimensional IP Routing", Mingwei Xu, Bo Wang, Tingfeng Wang, Jianping Wu, 2021-09-30, Segment Routing (SR) allows a headend node to steer traffic into a Segment Routing Policy (SR Policy), which represents the routing path by matching the destination address and the corresponding Binding Segment Identifier (BSID). However, determining the target SR Policy only based on destination aspect is incapable for demands for higher dimensional routing. Two Dimensional IP (TwoD-IP) routing is an Internet routing architecture that makes forwarding decisions based on source and destination addresses. TwoD-IP routing can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to the higher dimensional routing. In this document, we extend SR to support TwoD-IP routing, illustrate some typical scenarios of SR with TwoD-IP routing to express the advantage of extending SR to support TwoD-IP routing, and describe the mechanism of how TwoD IP routing protocol cooperates with SR. "Circuit Style Segment Routing Policies", Christian Schmutzer, Clarence Filsfils, Zafar Ali, Francois Clad, 2021-09-30, 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). "The Geohash HTTP Client Hint", Tommy Pauly, David Schinazi, 2021-09-30, This documents defines an HTTP Client Hint for sharing a client's rough location using the Geohash format. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. "Secure Vector Routing (SVR)", Abilash Menon, Michael Baj, Patrick Timmons, Hadriel Kaplan, 2021-10-01, This document describes Secure Vector Routing (SVR). Secure Vectors contain application layer metadata used for authentication and communicating network intent between data routers. The metadata is extensible, and could be used to transmit information, network routes, security policies, and quality policies securely across network boundaries. Boundaries include those formed by private network RFC1918 networks with the IPv4 public internet, and the IPv6 public internet. "DMARC Compliant Mailing Lists", Douglas Foster, 2021-10-03, Mailing Lists often make changes to a message before it is retransmitted. This invalidates DKIM signatures, causing a DMARC test on the RFC5322.From addres to fail. A DMARC-compliant mailing list is one which uses member alias addresses to identify the document as sent by a specific author via the mechanism of the list. An appropriate aliasing mechanism will not only prevent DMARC FAIL, but will also allow messages between members, will look natural to senders and recipients, and will allow list organization domains to advance to p=reject. This document describes an aliasing approach which meets these goals. "Distributed HTTP Origins: Solution Space Exploration", Mike Bishop, 2021-10-04, Certain content libraries are logically a single origin, but too large to be practically served by a single origin server. This document discusses existing solutions and explores possible directions for future protocol development. "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, 2021-10-04, This document contains a number of extensions to the PCAPng file format which are outside of the IETF networking mandate. "Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level", Murray Kucherawy, 2021-10-17, 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. "Host behavior to short prefix length", Akimichi Ogawa, Kaname Nishizuka, Yoshifumi Atarashi, Akira Kanai, 2021-10-05, The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit prefix length field. Prefix List entries are created using the prefix length in the Prefix Information Option. The Conceptual Model of a Host described in RFC 4861[RFC4861] does not clarify behavior of a host, when a short prefix length is received. This document updates RFC 4861(if approved), and clarifies that hosts SHOULD NOT accept prefix length shorter than /64. "Application-Oriented Literals in CBOR Extended Diagnostic Notation", Carsten Bormann, 2021-10-06, 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). "Retrofit Structured Fields for HTTP", Mark Nottingham, 2021-10-06, This specification defines how a selection of existing HTTP fields can be handled as Structured Fields. "TURN Cluster: Scale out TURN cluster by routable transaction id", William Zeng, 2021-10-07, The TURN protocol is designed to solve the connectivity problem of Peer-to-Peer Communication when NAT devices exist, by allowing each peer to establish a data channel on TURN servers. Since there are some specific requirements in the use of TURN, such as RTP/RTCP connection pairs must be sent to the same TURN server, it is not easy to scale a single TURN server into a TURN cluster. In addition, a TURN service cluster also needs to consider how to achieve good load balancing and how to protect internal information security. Based on these demands, this specification provides several standard means to implement a functional and secure TURN cluster, and this specification also provides an overview and rationale of the cluster architecture. "PCEP Extensions for Topology Filter", Quan Xiong, Shaofu Peng, Vishnu Beeram, Tarek Saad, Mike Koldychev, 2021-10-08, This document proposes a set of extensions for PCEP to support the topology filter during path computation. "YANG model for Data Export over IP Flow Information Export (IPFIX) Protocol", Anand Arokiaraj, Marta Seda, 2021-10-08, This document defines a flexible, modular YANG model for data export via the IPFIX protocol. The YANG models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "A Formal Language to Describe State Machines", Marc Petit-Huguenin, 2021-10-11, This document describes a meta-language for finite state machines. "Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, Alex Brotman, 2021-10-11, 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. "RADIUS attributes for Randomized and Changing MAC addresses", Jerome Henry, Nancy Cam-Winget, 2021-10-11, This document describes the means by which a Stable MAC address identifier can be signaled to a Authentication Authorization and Accounting (AAA) server. "DNS Data Dictionary", Heather Flanagan, Steve Crocker, 2021-10-11, Multiple applications related to the domain name system are built around a list of data elements. There is currently no unified public list of these data elements, nor is there an organized and independent change control process. This document codifies the multiple similar but not quite identical lists of data elements into a neutral DNS Data Dictionary to be maintained as an independent IANA Registry. "Self-Addressing IDentifier (SAID)", Samuel Smith, 2021-10-12, A SAID (Self-Addressing IDentifier) is a special type of content addressable identifier based on encoded cryptographic digest that is self-referential. The SAID derivation protocol defined herein enables verification that a given SAID is uniquely cryptographically bound to a serialization that includes the SAID as a field in that serialization. Embedding a SAID as a field in the associated serialization indicates a preferred content addressable identifier for that serialization that facilitates greater interoperability, reduced ambiguity, and enhanced security when reasoning about the serialization. Moreover given sufficient cryptographic strength, a cryptographic commitment such as a signature, digest, or another SAID, to a given SAID is essentially equivalent to a commitment to its associated serialization. Any change to the serialization invalidates its SAID thereby ensuring secure immutability evident reasoning with SAIDS about serializations or equivalently their SAIDs. Thus SAIDs better facilitate immutably referenced data serializations for applications such as Verifiable Credentials or Ricardian Contracts. SAIDs are encoded with CESR (Composable Event Streaming Representation) which includes a pre-pended derivation code that encodes the cryptographic suite or algorithm used to generate the digest. A CESR primitive's primary expression (alone or in combination ) is textual using Base64 URL Safe characters. CESR primitives may be round-tripped (alone or in combination) to a compact binary representation without loss. The CESR derivation code enables cryptographic digest algorithm agility in systems that use SAIDs as content addresses. Each serialization may use a different cryptographic digest algorithm as indicated by its derivation code. This provides interoperable future proofing. CESR was developed for the [KERI] protocol. "Requirements of large scale deterministic network", Peng Liu, Zongpeng Du, Yizhou Li, 2021-10-13, Aiming at the large scale deterministic network, this document specifies the technical and operational requirements when the different deterministic levels of applications co-exist and are transported over a wide area. "UDP-based Generic Multi-Access (GMA) Control Protocol", Jing Zhu, Menglei Zhang, 2021-10-13, 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. "Bundle Protocol Version 7 Administrative Record Types Registry", Brian Sipos, 2021-10-13, 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. "Requirements for MPLS Label Stack Indicators for Ancillary Data", Matthew Bocci, Stewart Bryant, 2021-10-14, This draft specifies requirements for indicators in the MPLS label stack of ancillary data that exists below the label stack. This work is the product of the IETF MPLS Open Design Team. Requirements are derived from a number of new 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, based on application data that may be in or below the bottom of the label stack. "PCEP Extension for L2 Flow Specification", Dhruv Dhody, Adrian Farrel, Zhenbin Li, 2021-10-14, The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering network. These paths may be supplied in response to requests for computation, or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC XXXX specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extends the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. RFC Editor Note: Please replace XXXX in the Abstract with the RFC number assigned to draft-ietf-pce-pcep-flowspec when it is published. Please remove this note. "Distributed Bump-in-the-wire Use Case", Yubao Wang, 2021-10-15, The Bump-in-the-wire use-case of Section 4.3 of [RFC9136] is a centerlized inter-subnet forwarding solution. The centerlized inter- subnet forwarding burdens the DGWs with the L3 traffics among different subnets inside the same DC. This draft extends the Bump-in-the-wire use-case of Section 4.3 of [RFC9136] in order to achieve a distributed inter-subnet forwarding solution. "VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong, 2021-10-15, 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, 2021-10-15, 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, 2021-10-16, 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. "Performance Analysis of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse, 2021-10-16, 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 and compares the performance of some free software implementations of the five most prominent IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T). "Extensions to the Access Control Lists (ACLs) YANG Model", Oscar de Dios, samier barguil, Mohamed Boucadair, 2021-10-18, 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. "Native Short Addressing for Low power and Lossy Networks Expansion", Guangpeng Li, Zhe Lou, Luigi Iannone, Peng Liu, 2021-10-18, This document specifies mechanisms of NSA (Native Short Address) that enables IP packet transmission over links where the transmission of a full length address may not be desirable. This document focuses on carrying IP packets across a LLN (Low power and Lossy Network), in which the nodes' location is fixed and changes in the logical topology are caused only by unstable radio connectivity (not physical mobility). The specifications include NSA allocation, routing mechanisms, header format design including length-variable fields, and IPv6 interconnection support. "A registry/registrar blockchain architecture for domain name registration data access protocol", Yu Zeng, Man Zhang, Wei Wang, 2021-10-18, This document defines a registry/registrar blockchain architecture for domain name registration data access protocol. "Internet Protocol version 16 (IPv16)", Bosubabu Sambana, 2021-10-18, The present invention Internet Protocol Version 16 (IPv16) service for allowing relates to the creation of an extended new version of Internet Protocol version 16 and its supports to current technologies and future technologies too without any interrupt. I propose New Internet Protocol version for technology upgradation and limitless end user connectivity and create new classes F and Class H, and Class I for extended to present classes and its performed Public, private, protected environment access with UWW for at the User Level, it is performed to operate both I and H Classes for Unlimited and Infinity High Security with multicast and Virtual IP address each block connectivity for an universal users and interstellar and expand universe users allocations. IP Address is run single IP address inherited desired Sub-IP address and extended upto X power n with Virtual IP and IP subsequences upto 2 power of x-n,proposed new series of 1024.1024.1024.1024 and VirtualIP works similar current way,and introduce Universal Wide Web (UWW) also Communicate Interstellar objects and Galaxies using Radio Signals are integrated with the proposed architecture, and Virtual IP - IPv16 to expand the internal space communications very quickly with secured allocated channels. Secured allocated individualrecognized block channels are connected with Internet and resolve tointerrupt signals and message transfer delayed problem, transfer data with secure way along with working mechanism the same existing technologies and IPv16 will adapt identifiedand undefined problems of IPv6 computer technology and network transmission problems to resolve the gaps between IPv6 to IPv16 and supports upcoming future technologies and versions too. "Relax the AS Loop Detection for Aggregates in BGP", Enke Chen, Stefan Olofsson, 2021-10-18, Currently an BGP aggregate may be denied or excluded by the AS loop detection mechanism when a more specific, contributing route contains the local AS number. To help enhance network robustness and simplify network operations, in this document we propose that the AS loop detection be relaxed for aggregates with an AS_SET path segment. "Problem Statement for Internet of Things Sensing", Dirk Hugo, Behcet Sarikaya, 2021-10-18, The document attempts to establish hardware based Internet of Things authentication as a future networking area beyond 5G going into 6G for standardization. The problem of hardware authentication is discussed and its relationship with Wireless Local Area network collaborative and/or multi-band sensing is established and then recent research efforts in the area are indicated. "Requirement and a Reference Model of L2 ACP based ANI", Yizhou Li, Yujing Zhou, Li Shen, 2021-10-19, This document discusses the scenarios, requirements and a reference model of ANI (Autonomic Networking Infrastructure) to be constructed in a layer 2 network using L2 Autonomic Control Plane (ACP) and the related functions. It expands the applicability of ANI to L2 network and maintains the same infrastructure. "IGP Extensions for Path MTU", Zhibo Hu, Shuping Peng, Xing Xi, 2021-10-19, Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths which are called segments. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS and OSPF extensions about the Path MTU that need to be used on SR. Here, the term "OSPF" means both OSPFv2 and OSPFv3. "Advertising S-BFD Discriminators in BGP", Haibo Wang, Yang Huang, Jie Dong, 2021-10-19, This document defines the method of transmitting S-BFD Discriminators through BGP attributes. This method helps services create S-BFD sessions more easily. "Updated Rules for PCEP Object Ordering", Dhruv Dhody, 2021-10-19, The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. Such interactions include 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. "RFC Series Responsibility Change", Brian Rosen, 2021-10-20, In RFCXXXX [RFC Editor, please replace with the RFC resulting from draft-iab-rfcefdp-rfced-model], responsibility for the RFC series moved to the RFC Series Working Group and the RFC Series Approval Board. This document updates RFC2026 to recognize this change. "YANG-CBOR: Allocating SID ranges for PEN holders", Carsten Bormann, 2021-10-19, YANG-CBOR, RFC XXXX (draft-ietf-core-yang-cbor) defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC YYYY (draft-ietf-core-sid) defines ways to allocate these SIDs on the basis of IANA registries. The present specification uses these SID allocation mechanisms to allocate 100 000 SIDs for each holder of the first 1 000 000 holders of IANA-registered Private Enterprise Numbers (PENs). "Use of Streams in BGP over QUIC", Alvaro Retana, Yingzhen Qu, 2021-10-19, This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency. "Advertising WebSocket support in the HTTPS resource record", Dragana Damjanovic, 2021-10-19, This specification introduces a way to advertise the support for the extended CONNECT feature that is used for running the WebSocket protocol over a single stream of an HTTP/2 and HTTP/3 connection using HTTPS resource records [HTTPSRR]. "Satellite Semantic Addressing for Satellite Constellation", Lin Han, Richard Li, 2021-10-19, 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, 2021-10-19, 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, 2021-10-19, 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, 2021-10-20, This document arguments that despite the ongoing research in routing and addressing and the Internet innovation, researchers and engineers lack a dedicated forum where they can interact. "Term limits for IETF Leadership Positions", Rich Salz, 2021-10-20, This document says that nobody can be picked by NomCom for a position more than two consecutive terms. It obsoletes some other documents, which ones are TBD. 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/richsalz/draft-rsalz-termlimits. "High-Precision Service Metrics", Alexander Clemm, John Strassner, Jerome Francois, 2021-10-20, This document defines a set of metrics for high-precision networking services. These metrics can be used to assess the service levels that are being delivered for a networking flow. Specifically, they can be used to determine the degree of compliance with which service levels are being delivered relative to service level objectives that were defined for the flow. The metrics can be used as part of flow records and/or accounting records. They can also be used to continuously monitor the quality with which high-precision networking service are being delivered. "Unicast Use of the Lowest Address in an IPv4 Subnet", Seth Schoen, John Gilmore, David Taht, Michael Karels, 2021-10-20, 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. "IP Proxying Support for HTTP", Tommy Pauly, David Schinazi, Alex Chernyakhovsky, Mirja Kuehlewind, Magnus Westerlund, 2021-10-21, 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. "Secure Credential Transfer", Dmitry Vinokurov, Matt Byington, Ben Chester, Matthias Lerch, Crystal Qin, Adam Bar-Niv, Nick Sha, 2021-10-21, 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. "BGP-LS Extensions for IS-IS Flood Reflectors", Jordan Head, Tony Przygienda, 2021-10-21, This document defines new BGP-LS (BGP Link-State) TLVs in order to carry IS-IS Flood Reflection information. "Guidance to the IETF Nominating Committee About Term Limits", Barry Leiba, 2021-10-21, In order to encourage more turnover in the IETF management bodies, this document provides strong guidance to the IETF Nominating Committee with regard to limiting the number of consecutive terms a given participant should be selected to serve in NomCom-appointed positions. Network Time Protocol (ntp) --------------------------- "Control Messages Protocol for Use with Network Time Protocol Version 4", Brian Haberman, 2020-09-28, This document describes the structure of the control messages that were historically used with the Network Time Protocol before the advent of more modern control and management approaches. These control messages have been used to monitor and control the Network Time Protocol application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated Network Time Protocol specification documented in RFC 5905. The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305. "A YANG Data Model for NTP", Nan Wu, Dhruv Dhody, Ankit Sinha, N Anil, Yi Zhao, 2021-03-08, This document defines a YANG data model for Network Time Protocol (NTP) implementations. The data model includes configuration data and state data. "NTP Interleaved Modes", Miroslav Lichvar, Aanchal Malhotra, 2021-10-18, This document extends the specification of Network Time Protocol (NTP) version 4 in RFC 5905 with special modes called the NTP interleaved modes, that enable NTP servers to provide their clients and peers with more accurate transmit timestamps that are available only after transmitting NTP packets. More specifically, this document describes three modes: interleaved client/server, interleaved symmetric, and interleaved broadcast. "Roughtime", Aanchal Malhotra, Adam Langley, Watson Ladd, Marcus Dansarie, 2021-05-24, This document specifies Roughtime - a protocol that aims to achieve rough time synchronization while detecting servers that provide inaccurate time and providing cryptographic proof of their malfeasance. "A Secure Selection and Filtering Mechanism for the Network Time Protocol", Neta Schiff, Danny Dolev, Tal Mizrahi, Michael Schapira, 2021-08-21, The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document specifies an extension to the NTPv4 client, named Chronos, which is used as a "watchdog" alongside NTPv4, and provides improved security against time shifting attacks. Chronos involves changes to the NTP client's system process only and is backwards compatible with NTPv4 servers. Chronos is also applicable to the emerging NTPv5, since it does not affect the wire protocol. "Alternative NTP port", Miroslav Lichvar, 2021-10-18, This document updates RFC 5905 to specify an alternative port for the Network Time Protocol (NTP) which is restricted to NTP messages that do not allow traffic amplification. "Roughtime Ecosystem", Watson Ladd, Marcus Dansarie, 2021-09-14, This document specifies the roles of Roughtime validators, clients, and servers in providing a ecosystem for secure time. "Updating the NTP Registries", Rich Salz, 2021-10-15, The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. Network Virtualization Overlays (nvo3) -------------------------------------- "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Fabio Maino, Larry Kreeger, Uri Elzur, 2021-09-22, This document describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with four new capabilities: support for multi-protocol encapsulation, support for operations, administration and maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e. Broadcast, Unknown unicast, or Multicast), and explicit versioning. New protocol capabilities can be introduced via shim headers. "NVO3 Encapsulation Considerations", Sami Boutros, Donald Eastlake, 2021-07-29, As communicated by the WG Chairs, the IETF NVO3 chairs and Routing Area director have chartered a design team to take forward the encapsulation discussion and see if there is potential to design a common encapsulation that addresses the various technical concerns. There are implications of different encapsulations in real environments consisting of both software and hardware implementations and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. The design team recommends Geneve with a few modifications as the common encapsulation. This document provides more details, particularly in Section 7. "Applicability of EVPN to NVO3 Networks", Jorge Rabadan, Matthew Bocci, Sami Boutros, Ali Sajassi, 2020-11-02, In NVO3 networks, Network Virtualization Edge (NVE) devices sit at the edge of the underlay network and provide Layer-2 and Layer-3 connectivity among Tenant Systems (TSes) of the same tenant. The NVEs need to build and maintain mapping tables so that they can deliver encapsulated packets to their intended destination NVE(s). While there are different options to create and disseminate the mapping table entries, NVEs may exchange that information directly among themselves via a control-plane protocol, such as EVPN. EVPN provides an efficient, flexible and unified control-plane option that can be used for Layer-2 and Layer-3 Virtual Network (VN) service connectivity. This document describes the applicability of EVPN to NVO3 networks and how EVPN solves the challenges in those networks. "Base YANG Data Model for NVO3 Protocols", Bing Liu, Ran Chen, Fengwei Qin, Reshad Rahman, 2021-09-06, This document describes the base YANG data model that can be used by operators to configure and manage Network Virtualization Overlay protocols. The model is focused on the common configuration requirement of various encapsulation options, such as VXLAN, NVGRE, GENEVE and VXLAN-GPE. Using this model as a starting point, incremental work can be done to satisfy the requirement of a specific encapsulation. "OAM for use in GENEVE", Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti, 2021-05-17, This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. "BFD for Geneve", Xiao Min, Greg Mirsky, Santosh Pallagatti, Jeff Tantsura, Sam Aldrin, 2021-08-02, This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network. Coding for efficient NetWork Communications Research Group (nwcrg) ------------------------------------------------------------------ "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges", Kazuhisa Matsuzono, Hitoshi Asaeda, Cedric Westphal, 2021-07-27, This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN), and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG). "Coding and congestion control in transport", Nicolas Kuhn, Emmanuel Lochin, Francois Michel, Michael Welzl, 2021-06-25, Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications: FEC coding for tunnels is out-of-the scope of the document. "BATS Coding Scheme for Multi-hop Data Transport", Shenghao Yang, Xuan Huang, Raymond Yeung, John Zao, 2021-07-28, BATS code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code, and batch- based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks, and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). Web Authorization Protocol (oauth) ---------------------------------- "JWT Response for OAuth Token Introspection", Torsten Lodderstedt, Vladimir Dzhuvinov, 2021-09-04, This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. "OAuth 2.0 for Browser-Based Apps", Aaron Parecki, David Waite, 2021-05-17, This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. "OAuth 2.0 Rich Authorization Requests", Torsten Lodderstedt, Justin Richer, Brian Campbell, 2021-10-18, This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in the OAuth authorization request. "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)", Daniel Fett, Brian Campbell, John Bradley, Torsten Lodderstedt, Michael Jones, David Waite, 2021-10-04, This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. "The OAuth 2.1 Authorization Framework", Dick Hardt, Aaron Parecki, Torsten Lodderstedt, 2021-10-05, The OAuth 2.1 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. "OAuth 2.0 Authorization Server Issuer Identification", Karsten zu Selhausen, Daniel Fett, 2021-10-06, This document specifies a new parameter iss that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". Open Specification for Pretty Good Privacy (openpgp) ---------------------------------------------------- "OpenPGP Message Format", Werner Koch, Paul Wouters, 2021-10-18, { Work in progress to update the OpenPGP specification from RFC4880 } 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. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Network Telemetry Framework", Haoyu Song, Fengwei Qin, Pedro Martinez-Julia, Laurent Ciavaglia, Aijun Wang, 2021-10-13, Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminologies and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. "A Layer 3 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed Boucadair, Luis Munoz, Alejandro Aguado, 2021-10-08, As a complement to the Layer 3 Virtual Private Network Service YANG data Model (L3SM), used for communication between customers and service providers, this document defines an L3VPN Network YANG Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate the communication between a service orchestrator and a network controller/orchestrator. "A Layer 2 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed Boucadair, Luis Munoz, 2021-10-20, This document defines an L2VPN Network YANG Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a network-centric view of the service that is internal to a service providers. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, the document defines the initial versions of two IANA- maintained modules that defines a set of identities of BGP Layer 2 encapsulation types and pseudowire types. "A Layer 2/3 VPN Common YANG Model", samier barguil, Oscar de Dios, Mohamed Boucadair, Qin WU, 2021-09-29, This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: * "This version of this YANG module is part of RFC XXXX;" * "RFC XXXX: A Layer 2/3 VPN Common YANG Model"; * reference: RFC XXXX Also, please update the "revision" date of the YANG module. "Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices", Tirumaleswar Reddy.K, Dan Wing, Blake Anderson, 2021-07-27, This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. "Discovering and Retrieving Software Transparency and Vulnerability Information", Eliot Lear, Scott Rose, 2021-07-09, To improve cybersecurity posture, automation is necessary to locate what software is running on a device, whether that software has known vulnerabilities, and what, if any recommendations suppliers may have. This memo specifies a model to provide access this information. It may optionally be discovered through manufacturer usage descriptions. "Authorized update to MUD URLs", Michael Richardson, Wei Pan, Eliot Lear, 2021-10-06, This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls "Operational Considerations for use of DNS in IoT devices", Michael Richardson, Wei Pan, 2021-07-11, This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document explains the problem through a series of examples of what can go wrong, and then provides some advice on how a device manufacturer can best make deal with these issues. The recommendations have an impact upon device and network protocol design. {RFC-EDITOR, please remove. Markdown and issue tracker for this document is at https://github.com/mcr/iot-mud-dns-considerations.git } "A YANG Model for Network and VPN Service Performance Monitoring", Bo Wu, Qin WU, Mohamed Boucadair, Oscar de Dios, Bin Wen, Chang Liu, Honglei Xu, 2021-07-06, The data model defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for both network performance monitoring (PM) and VPN service performance monitoring that can be used to monitor and manage network performance on the topology at higher layer or the service topology between VPN sites. The YANG model defined in this document is designed as an augmentation to the network topology YANG model defined in RFC 8345 and draws on relevant YANG types defined in RFC 6991, RFC 8345, and RFC 8532. "Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)", Thomas Graf, 2021-09-17, This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol used within a Segment Routing domain. In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for PCE, IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. "Service Assurance for Intent-based Networking Architecture", Benoit Claise, Jean Quilbeuf, Diego Lopez, Dan Voyer, Thangam Arumugam, 2021-07-02, This document describes an architecture for Service Assurance for Intent-based Networking (SAIN). This architecture aims at assuring that service instances are running as expected. As services rely upon multiple sub-services provided by the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with the network root cause but also the impacted services when a network component fails or degrades. "YANG Modules for Service Assurance", Benoit Claise, Jean Quilbeuf, Paolo Lucente, Paolo Fasano, Thangam Arumugam, 2021-07-02, This document proposes YANG modules for the Service Assurance for Intent-based Networking Architecture. "Ownership and licensing statements in YANG", Eliot Lear, Carsten Bormann, 2021-10-20, This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", Fernando Gont, Will LIU, 2021-06-03, This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic *not* directed to them, for those cases where such filtering is deemed as necessary. Path Aware Networking RG (panrg) -------------------------------- "Current Open Questions in Path Aware Networking", Brian Trammell, 2021-10-11, In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet. This document poses questions in path-aware networking open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking proposed Research Group (PANRG), and has been published to snapshot current thinking in this space. "A Vocabulary of Path Properties", Theresa Enghardt, Cyrill Krahenbuhl, 2021-07-09, Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as hosts. This document defines and categorizes path properties. Furthermore, the document specifies several path properties which might be useful to hosts or other entities, e.g., for selecting between paths or for invoking some of the provided services. Path Computation Element (pce) ------------------------------ "Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications", Helia Poullyau, Remi Theillaud, Julien Meuric, Haomian Zheng, Xian Zhang, 2021-08-26, This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) specified in RFC5440, and will update it. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft defines types of errors and how they are disclosed to other PCEs in order to support predefined PCEP behaviors. "Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks", Young Lee, Haomian Zheng, Oscar de Dios, Victor Lopez, Zafar Ali, 2021-06-23, The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. "PCEP Extension for Flow Specification", Dhruv Dhody, Adrian Farrel, Zhenbin Li, 2021-10-14, The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering network. These paths may be supplied in response to requests for computation, or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP, and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. "PCEP Extension for Native IP Network", Aijun Wang, Boris Khasanov, Sheng Fang, Ren Tan, Chun Zhu, 2021-08-15, This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [RFC8735] and [RFC8821]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. "PCEP Extension for Flexible Grid Networks", Young Lee, Haomian Zheng, Ramon Casellas, Ricard Vilalta, Daniele Ceccarelli, Francesco Lazzeri, 2021-09-08, This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", Cheng Li, Mahendra Negi, Siva Sivabalan, Mike Koldychev, Prejeeth Kaladharan, Yongqing Zhu, 2021-05-27, The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State IGPs. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in RFC 8664. This document extends it to support SRv6 (SR over IPv6). "Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, 2021-10-15, This document describes how to extend Path Computation Element (PCE) Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, to further associate sets of LSPs with a higher-level structure such as a virtual network (VN) requested by clients or applications. This extended association mechanism can be used to facilitate virtual network control using PCE architecture. "Carrying Binding Label/Segment Identifier in PCE-based Networks.", Siva Sivabalan, Clarence Filsfils, Jeff Tantsura, Stefano Previdi, Cheng Li, 2021-10-15, In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID). It is possible to associate a BSID to an RSVP-TE- signaled Traffic Engineering Label Switched Path or an SR Traffic Engineering path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the binding value as an MPLS label or Segment Identifier. It further specifies an approach for reporting binding label/Segment Identifier (SID) by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based Traffic Engineering policies. "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2021-08-12, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths", Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2021-09-09, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. "PCEP extension to support Segment Routing Policy Candidate Paths", Mike Koldychev, Siva Sivabalan, Colby Barth, Shuping Peng, Hooman Bidgoli, 2021-05-23, This document introduces a mechanism to specify a Segment Routing (SR) policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can contain one or more candidate paths where each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. This document proposes extension to PCEP to support association among candidate paths of a given SR policy. The mechanism proposed in this document is applicable to both MPLS and IPv6 data planes of SR. "Local Protection Enforcement in PCEP", Andrew Stone, Mustapha Aissaoui, Samuel Sidor, Siva Sivabalan, 2021-08-05, This document updates [RFC5440] to clarify usage of the local protection desired bit signalled in Path Computation Element Protocol (PCEP). This document also introduces a new flag for signalling protection strictness in PCEP. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution.", Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou, 2021-09-30, 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. Thus, the LSP can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. "PCEP Extension for Stateful Inter-Domain Tunnels", Olivier Dugeon, Julien Meuric, Young Lee, Daniele Ceccarelli, 2021-07-12, This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. For this purpose, this document defines a new Stitching Label, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. "LSP Object Flag Extension of Stateful PCE", Quan Xiong, 2021-10-18, RFC 8231 describes a set of extensions to Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. One of the extensions is the LSP object which includes a Flag field of the length of 12 bits. However, 11 bits of the Flag field have already been assigned in RFC 8231, RFC 8281 and RFC 8623. This document proposes to define a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended flag field. "PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, 2021-10-17, Path computation algorithms are not limited to return a single optimal path. Multiple paths may exist that satisfy the given objectives and constraints. This document defines a mechanism to encode multiple paths for a single set of objectives and constraints. This is a generic PCEP mechanism, not specific to any path setup type or dataplane. The mechanism is applicable to both stateless and stateful PCEP. "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng, 2021-10-20, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. "Extension for Stateful PCE to allow Optional Processing of PCEP Objects", Cheng Li, Haomian Zheng, Stephane Litkowski, 2021-10-12, This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints. This document introduces this relaxation and updates RFC 8231. Privacy Enhancements and Assessments Research Group (pearg) ----------------------------------------------------------- "Guidelines for Performing Safe Measurement on the Internet", Iain Learmonth, Gurshabad Grover, Mallory Knodel, 2021-07-12, Researchers from industry and academia often use Internet measurements as part of their work. While these measurements can give insight into the functioning and usage of the Internet, they can come at the cost of user privacy. This document describes guidelines for ensuring that such measurements can be carried out safely. Note Comments are solicited and should be addressed to the research group's mailing list at pearg@irtf.org and/or the author(s). The sources for this draft are at: https://github.com/irl/draft-safe-internet-measurement "Unfortunate History of Transient Numeric Identifiers", Fernando Gont, Ivan Arce, 2021-06-13, This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. Privacy Enhanced RTP Conferencing (perc) ---------------------------------------- "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", Paul Jones, Paul Ellenbogen, Nils Ohlmeier, 2021-09-23, This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the Media Distributor. Protocols for IP Multicast (pim) -------------------------------- "A YANG Data Model for Protocol Independent Multicast (PIM)", Xufeng Liu, Pete McAllister, Anish Peter, Mahesh Sivakumar, Yisong Liu, fangwei hu, 2018-05-19, This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). The model covers the PIM protocol configuration, operational state, and event notifications data. "Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement", Zheng Zhang, fangwei hu, BenChong Xu, Mankamana Mishra, 2021-08-15, Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. "A Yang Data Model for IGMP and MLD Snooping", Hongji Zhao, Xufeng Liu, Yisong Liu, Mahesh Sivakumar, Anish Peter, 2021-10-08, This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). "PIM Null-Register packing", Vikas Kamath, Ramakrishnan Sundaram, Raunak Banthia, Ananya Gopal, 2021-09-11, In PIM-SM networks PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of Multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single Multicast source and group. This document defines a standard to send multiple multicast source and group information in a single PIM Null-Register message, in a packed format. We will refer to this packed format as the PIM Packed Null-Register format throughout the document. This document also discusses the interoperability between the PIM routers which do not understand the packed message format with multiple multicast source and group details. "Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks", Greg Mirsky, Ji Xiaoli, 2021-10-07, This document specifies how Bidirectional Forwarding Detection for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to- multipoint BFD session is also defined in this document. "A Yang Data Model for IGMP/MLD Proxy", Hongji Zhao, Xufeng Liu, Yisong Liu, Mani Panchanathan, Mahesh Sivakumar, 2021-08-30, This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) proxy devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). "PIM Assert Message Packing", Yisong Liu, Mike McBride, Toerless Eckert, Zheng Zhang, 2021-10-20, In PIM-SM shared LAN networks, there is typically more than one upstream router. When duplicate data packets appear on the LAN from different routers, assert packets are sent from these routers to elect a single forwarder. The PIM assert packets are sent periodically to keep the assert state. The PIM assert packet carries information about a single multicast source and group, along with the metric-preference and metric of the route towards the source or RP. This document defines a standard to send and receive information for multiple multicast sources and groups in a single PIM assert message. This can be particularly helpful when there is traffic for a large number of multicast groups. "IGMPv3/MLDv2 Message Extension", Mahesh Sivakumar, Stig Venaas, Zheng Zhang, Hitoshi Asaeda, 2021-01-21, IGMP and MLD protocols are extensible, but no extensions have been defined so far. This document provides a well-defined way of extending IGMP and MLD, using a list of TLVs (Type, Length and Value). "Segment Routing Point-to-Multipoint Policy", Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2021-08-23, This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE. "PIM Backup Designated Router Procedure", Mankamana Mishra, Sridhar Santhanam, Aravind Paramasivam, Joseph Goh, Gyan Mishra, 2021-09-10, On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it. "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Brian Haberman, 2021-09-28, This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. "Internet Group Management Protocol, Version 3", Brian Haberman, 2021-09-28, This document specifies a revised Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 3376. Privacy Pass (privacypass) -------------------------- "Privacy Pass HTTP API", Steven Valdez, 2021-07-12, This document specifies an integration for Privacy Pass over an HTTP API, along with recommendations on how key commitments are stored and accessed by HTTP-based consumers. Quantum Internet Research Group (qirg) -------------------------------------- "Architectural Principles for a Quantum Internet", Wojciech Kozlowski, Stephanie Wehner, Rodney Van Meter, Bruno Rijsman, Angela Cacciapuoti, Marcello Caleffi, Shota Nagayama, 2021-06-04, The vision of a quantum internet is to fundamentally enhance Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first realisations of quantum entanglement networks are imminent, but there is no practical proposal for how to organise, utilise, and manage such networks. In this memo, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest, but also to provide a foundation for discussion between physicists and network specialists. This document is a product of the Quantum Internet Research Group (QIRG). "Application Scenarios for the Quantum Internet", Chonggang Wang, Akbar Rahman, Ruidong Li, Melchior Aelmans, Kaushik Chakraborty, 2021-08-20, The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the Quantum Internet, and then categorizes them using various classification schemes. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to describe a framework for applications, and describe a few selected application scenarios for the Quantum Internet. This document is a product of the Quantum Internet Research Group (QIRG). QUIC (quic) ----------- "Hypertext Transfer Protocol Version 3 (HTTP/3)", Mike Bishop, 2021-02-02, The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http. "Applicability of the QUIC Transport Protocol", Mirja Kuehlewind, Brian Trammell, 2021-09-02, This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC, and implementors of these application protocols. "Manageability of the QUIC Transport Protocol", Mirja Kuehlewind, Brian Trammell, 2021-09-02, This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. "QPACK: Header Compression for HTTP/3", Charles Krasic, Mike Bishop, Alan Frindell, 2021-02-02, This specification defines QPACK, a compression format for efficiently representing HTTP fields, to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking. "QUIC-LB: Generating Routable QUIC Connection IDs", Martin Duke, Nick Banks, 2021-10-04, The QUIC protocol design is resistant to transparent packet inspection, injection, and modification by intermediaries. However, the server can explicitly cooperate with network services by agreeing to certain conventions and/or sharing state with those services. This specification provides a standardized means of solving three problems: (1) maintaining routability to servers via a low-state load balancer even when the connection IDs in use change; (2) explicit encoding of the connection ID length in all packets to assist hardware accelerators; and (3) injection of QUIC Retry packets by an anti-Denial-of-Service agent on behalf of the server. "Compatible Version Negotiation for QUIC", David Schinazi, Eric Rescorla, 2021-05-26, QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client offered is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the original and negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. "An Unreliable Datagram Extension to QUIC", Tommy Pauly, Eric Kinnear, David Schinazi, 2021-10-05, This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/quicwg/ datagram (https://github.com/quicwg/datagram). "Greasing the QUIC Bit", Martin Thomson, 2021-10-18, This document describes a method for negotiating the ability to send an arbitrary value for the second-to-most significant bit in QUIC packets. "Main logging schema for qlog", Robin Marx, Luca Niccolini, Marten Seemann, 2021-06-10, This document describes a high-level schema for a standardized logging format called qlog. This format allows easy sharing of data and the creation of reusable visualization and debugging tools. The high-level schema in this document is intended to be protocol- agnostic. Separate documents specify how the format should be used for specific protocol data. The schema is also format-agnostic, and can be represented in for example JSON, csv or protobuf. "QUIC event definitions for qlog", Robin Marx, Luca Niccolini, Marten Seemann, 2021-06-10, This document describes concrete qlog event definitions and their metadata for QUIC events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. "HTTP/3 and QPACK event definitions for qlog", Robin Marx, Luca Niccolini, Marten Seemann, 2021-06-10, This document describes concrete qlog event definitions and their metadata for HTTP/3 and QPACK-related events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. "QUIC Acknowledgement Frequency", Jana Iyengar, Ian Swett, 2021-07-12, This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Real-time Applications and Infrastructure Area (rai) ---------------------------------------------------- "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 Servi