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-01-23 02:06:11 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, 2020-12-07, 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. "Packet Delivery Deadline time in 6LoWPAN Routing Header", Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins, 2019-07-08, This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT machine to machine (M2M) applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values. "Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2020-10-28, 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) ----------------------- "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves, 2020-11-02, This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate global scope addresses with randomized interface identifiers that change over time. Changing global scope addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC4941. "Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)", Zafar Ali, Clarence Filsfils, Satoru Matsushima, Daniel Voyer, Mach Chen, 2020-10-30, 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, 2020-10-23, This document specifies a new Hop-by-Hop IPv6 option that is used to record the minimum Path MTU along the forward path between a source host to a destination host. This collects a minimum Path MTU recorded along the path to the destination. The value can then be communicated back to the source using the return Path MTU field in the option. This Hop-by-Hop option is intended to be used in environments like Data Centers and on paths between Data Centers, to allow them to better take advantage of paths able to support a large Path MTU. The method could also be useful in other environments, including the general Internet. "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers", Jen Linkova, 2020-09-15, Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node. It also updates RFC4861 and recommends nodes to send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. The proposed change will minimize the delay and packet loss when a node initiate connections to off-link destination from a new IPv6 address. "IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fengwei Qin, Ran Pang, 2020-10-13, This document describes how the Alternate Marking Method can be used as the passive performance measurement tool in an IPv6 domain and reports implementation considerations. It proposes how to define a new Extension Header Option to encode alternate marking technique and both Hop-by-Hop Options Header and Destination Options Header are considered. "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson, 2021-01-19, In renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Pascal Thubert, 2020-11-26, This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications. "Constrained Join Protocol (CoJP) for 6TiSCH", Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson, 2019-12-10, This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. "IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information", Diego Dujovne, Michael Richardson, 2020-02-21, In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a Time- Slotted Channel Hopping (TSCH) network transmit Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon in order to conserve use of broadcast opportunities. "6TiSCH Minimal Scheduling Function (MSF)", Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne, 2020-09-12, This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. 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, 2020-11-16, 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-01-20, 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, 2020-12-14, This memo 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, 2020-04-28, 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, 2020-11-02, 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, 2020-11-02, This specification 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, 2020-12-18, 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-01-03, This specification defines an application profile for authentication and authorization for publishers and subscribers in a pub-sub setting scenario in a constrained environment, using the ACE framework. This profile relies on transport layer or application layer security to authorize the publisher to the broker. Moreover, it relies on application layer security for publisher-broker and subscriber-broker communication. "An Authorization Information Format (AIF) for ACE", Carsten Bormann, 2020-07-29, 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 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 and the permissions on them. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, Klaus Hartke, 2020-11-02, 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 key 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "Extensions to Automatic Certificate Management Environment for end-user S/MIME certificates", Alexey Melnikov, 2020-11-20, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME. "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock, Mary Barnes, Jon Peterson, 2020-03-09, 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, 2020-03-09, 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. "An ACME Profile for Generating Delegated STAR Certificates", Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2020-08-25, This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner of a domain name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem. "ACME End User Client and Code Signing Certificates", Kathleen Moriarty, 2020-10-05, 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, 2020-11-18, 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, 2020-08-26, 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 Uniform Resource Identifier (URI) and ACME Identifier type "uri". Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Performance Cost Metrics", Qin WU, Y. Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, Luis Contreras, 2021-01-13, 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, J. Zhang, 2020-11-20, 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, J. Zhang, Kai Gao, 2020-11-26, This document extends the base Application-Layer Traffic Optimization (ALTO) Protocol by generalizing the concept of "endpoint properties" to generic types of entities, and by presenting those properties 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) ---------------------------------------------------------- "A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian Carpenter, Bing Liu, 2017-07-13, This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. "An Autonomic Control Plane (ACP)", Toerless Eckert, Michael Behringer, Steinthor Bjarnason, 2020-10-30, Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin, Michael Richardson, Toerless Eckert, Michael Behringer, Kent Watsen, 2020-11-11, This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. "A Reference Model for Autonomic Networking", Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Jeferson Nobre, 2018-11-22, This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun, 2017-12-18, This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong, 2021-01-04, This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems. "Constrained Voucher Artifacts for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2020-11-02, 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 builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-est] protocol. "Information Distribution over GRASP", Bing Liu, Xun Xiao, Artur Hecker, Sheng Jiang, Zoran Despotovic, Brian Carpenter, 2020-09-01, This document proposes a solution for information distribution in the autonomic network infrastructure (ANI). Information distribution is categorized into two different modes: 1) instantaneous distribution and 2) publication 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. The capability to distribute information is a basic and fundamental need for an autonomous network ([RFC7575]). This document describes typical use cases of information distribution in ANI and requirements to ANI, such that rich information distribution can be natively supported. The document proposes 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-01-07, This document describes enhancements of bootstrapping a remote secure key infrastructure (BRSKI) to also operate in domains featuring no or only timely limited connectivity between involved components. Moreover, newly introduced are methods to perform the BRSKI approach in environments, in which the role of the pledge changes to a server instead of the client. This changes the interaction model as the pledge is pushed to interact with the registrar instead of pulling information from the registrar. To support both, BRSKI-AE relies on the exchange of it 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, 2020-11-14, This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks, as a contribution to describing an autonomic ecosystem. It is based on the Autonomic Network Infrastructure outlined in the ANIMA reference model, using the Autonomic Control Plane and the Generic Autonomic Signaling Protocol. "Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2020-12-02, 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 [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- proxy by a stateless/stateful constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per-client state. Applications and Real-Time Area (art) ------------------------------------- "Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9", Sean Leonard, 2017-11-13, PKCS #9 includes several useful definitions that are not yet reflected in the LDAP IANA registry. This document adds those definitions to the IANA registry. "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. "New protocol elements for HTTP Status Code 451", Shivan Sahib, 2018-08-01, This document recommends additional protocol elements to Hypertext Transfer Protocol (HTTP) status code 451 (defined by RFC7725). Discussion of this document was conducted on the Human Rights Protocol Considerations Research Group mailing list https://www.irtf.org/mailman/listinfo/hrpc [1], briefly on the HTTPBIS Working Group mailing list ietf-http-wg@w3.org [2] and on https://lists.ghserv.net/mailman/listinfo/statuscode451 [3]. "The secret-token URI Scheme", Mark Nottingham, 2020-10-18, This document registers the "secret-token" URI scheme, to aid in the identification of authentication tokens. "IDNA2008 and Unicode 12.0.0", Patrik Faltstrom, 2019-03-11, This document describes the changes between Unicode 6.3.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. Although 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 i18nrp@ietf.org mailing list of the IETF. "Robots Exclusion Protocol", Martijn Koster, Gary Illyes, Henner Zeller, Lizzi Harvey, 2020-12-08, This document standardizes and extends the "Robots Exclusion Protocol" 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. "Zstandard Compression and the application/zstd Media Type", Yann Collet, Murray Kucherawy, 2020-12-18, Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME). It also registers a corresponding media type, content encoding, and structured syntax suffix. Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. "React: Indicating Summary Reaction to a Message", Dave Crocker, R. Signes, Ned Freed, 2021-01-18, The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail. 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, 2020-11-15, 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 the previous (-00) version of this document. SDF 1.1 is expected to be defined in a future version; the present document represents a draft on the way from 1.0 to 1.1. Hence, this is not an implementation draft. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas Nandakumar, 2020-08-04, This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Sebastien Lugan, Antonin Descampe, Corentin Damman, Thomas Richter, Tim Bruylants, 2020-11-27, 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 frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. "RTP Payload Format for Versatile Video Coding (VVC)", Shuai Zhao, Stephan Wenger, Yago Sanchez, Ye-Kui Wang, 2021-01-19, 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. "RTP-mixer formatting of multi-party Real-time text", Gunnar Hellstrom, 2020-12-15, Real-time text mixers for multi-party sessions need to identify the source of each transmitted group of text so that the text can be presented by endpoints in suitable grouping with other text from the same source, while new text from other sources is also presented in readable grouping as received interleaved in real-time. Use of RTT is increasing, and specifically, use in emergency calls is increasing. Emergency call use requires multi-party mixing. RFC 4103 "RTP Payload for Text Conversation" mixer implementations can use traditional RTP functions for source identification, but the performance of the mixer when giving turns for the different sources to transmit is limited when using the default transmission characteristics with redundancy. Enhancements for RFC 4103 real-time text mixing are provided in this document, suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multi-party real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multi-party coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multi-party aware is also provided. "Completely Encrypting RTP Header Extensions and Contributing Sources", Justin Uberti, Cullen Jennings, 2020-11-02, 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. "Multiplexing Scheme Updates for QUIC", Bernard Aboba, Gonzalo Salgueiro, Colin Perkins, 2020-11-21, 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. "RTP Payload Format for Essential Video Coding (EVC)", Shuai Zhao, Stephan Wenger, 2021-01-03, This memo describes an RTP payload format for the video coding standard ISO/IEC International Standard 23094-1 [ISO23094-1], also known as Essential Video Coding [EVC] and developed by ISO/IEC JTC1/SC29/WG11. 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. 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) ------------------------------ "Babel Information Model", Barbara Stark, Mahesh Jethanandani, 2020-08-14, This Babel Information Model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz Chroboczek, 2020-10-28, Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. "YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark, 2020-06-28, 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", Theophile Bastian, Juliusz Chroboczek, 2020-10-20, 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. BGP Enabled ServiceS (bess) --------------------------- "Integrated Routing and Bridging in EVPN", Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan, 2020-10-13, Ethernet VPN (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. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, John Drake, 2018-03-02, This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) devices. "IP Prefix Advertisement in EVPN", Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi, 2018-05-18, The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. "Multicast VPN Fast Upstream Failover", Thomas Morin, Robert Kebler, Greg Mirsky, 2021-01-21, This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using RFC 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks and the new BGP Attribute - BFD Discriminator. Also, the document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. "Optimized Ingress Replication solution for EVPN", Jorge Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi, 2020-07-13, 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 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 EVPN Networks", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Greg Hankins, Thomas King, 2021-01-07, This document describes the EVPN Proxy-ARP/ND function, augmented by the capability of the ARP/ND Extended Community [I-D.ietf-bess-evpn-na-flags]. From that perspective this document updates [RFC7432]. The EVPN Proxy-ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points (IXPs), Data Centers (DCs), and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains (DBs) 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, 2019-11-18, 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. "BGP Control Plane for the Network Service Header in Service Function Chaining", Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil, 2020-08-21, This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC Address Family Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header defined in RFC 8300. This document adopts the SFC architecture described in RFC 7665. "Propagation of ARP/ND Flags in EVPN", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wen Lin, 2020-12-01, This document defines an Extended Community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND or ARP/ND (on IRB interfaces) function can reply to ARP Requests or Neighbor Solicitations with the correct information. "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", Adrian Farrel, John Drake, Eric Rosen, Keyur Patel, Luay Jalil, 2021-01-05, Data centers are critical components of the infrastructure used by network operators to provide services to their customers. Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load balancing, and resiliency reasons. Segment Routing is a protocol mechanism that can be used within a data center, and also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site, it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment Routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the Segment Routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same Segment Routing domain. "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2020-10-13, 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. "MVPN and MSDP SA Interoperation", Zhaohui Zhang, Leonard Giuliano, 2020-05-26, This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source Active routes and customer Multicast Source Discovery Protocol (MSDP) Source Active routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the PEs that are customer MSDP peers. This document updates RFC6514. "EVPN VPWS Flexible Cross-Connect Service", Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Sami Boutros, Jorge Rabadan, 2020-09-08, 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. "Per multicast flow Designated Forwarder Election for EVPN", Ali Sajassi, Mankamana Mishra, Samir Thoria, Jorge Rabadan, John Drake, 2020-08-31, [RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow). "Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing", Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria, 2020-10-14, In an EVPN-IRB based network overlay, EVPN all-active multi-homing enables multi-homing for a CE device connected to two or more PEs via a LAG, such that bridged and routed traffic from remote PEs can be equally load balanced (ECMPed) across the multi-homing PEs. 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 PE-CE links within the access LAG. o handle PE-CE LAG member 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-01-11, 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 Operations, Administration and Maintenance Requirements and Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald Eastlake, 2020-07-08, This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. "EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, Eric Rosen, John Drake, Wen Lin, Jim Uttaro, Adam Simpson, 2020-12-19, 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, Avinash Lingala, Jorge Rabadan, John Drake, 2020-10-27, 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, 2020-08-13, 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. "PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Masahiro Miyake, Taku Matsuda, 2020-10-30, 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, 2020-11-02, 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, 2020-09-22, This document specifies a way that one or more centralized controllers can use BGP to set up a multicast distribution tree in a network. In the case of labeled tree, the labels are assigned by the controllers either from the controllers' local label spaces, or from a common Segment Routing Global Block (SRGB), or from each routers Segment Routing Local Block (SRLB) that the controllers learn. In case of labeled unidirectional tree and label allocation from the common SRGB or from the controllers' local spaces, a single common label can be used for all routers on the tree to send and receive traffic with. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. "BGP Based Multicast", Zhaohui Zhang, Leonard Giuliano, Keyur Patel, IJsbrand Wijnands, Mankamana Mishra, Arkadiy Gulko, 2021-01-07, This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multiast trees. "Fault Management for EVPN networks", Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake, 2020-11-02, This document specifies proactive, in-band network OAM mechanisms to detect loss of continuity and miss-connection faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN) network. The mechanisms specified in the draft are based on the widely adopted Bidirectional Forwarding Detection (BFD) protocol. "BGP Usage for SDWAN Overlay Networks", Linda Dunbar, Jim Guichard, Ali Sajassi, John Drake, Basil Najem, David Carrel, 2021-01-22, The document discusses the usage and applicability of BGP as control plane for multiple SDWAN scenarios. The goal of the document is to demonstrate how BGP-based control plane is used for large scale SDWAN overlay networks with little manual intervention. SDWAN edge nodes are commonly interconnected by multiple underlay networks which can be owned and managed by different network providers. "EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan, Kiran Nagaraj, Wen Lin, Ali Sajassi, 2020-10-12, 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 Point-to-Multipoint Trees", Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Daniel Voyer, Zhaohui Zhang, 2020-12-02, A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain efficiently carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees used in BGP/MPLS IP VPNs and Ethernet VPNs. "BGP MPLS-Based Ethernet VPN", Ali Sajassi, John Drake, Jorge Rabadan, 2020-12-22, 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)". "Multicast Source Redundancy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Wen Lin, Eric Rosen, 2021-01-18, 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. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Santosh Pallagatti, Greg Mirsky, 2018-08-02, This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, 2020-07-27, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880. "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen, Peng Fan, 2021-01-14, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD packet loss. "Secure BFD Sequence Numbers", Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, Alan DeKok, 2020-12-16, This document describes a security enhancement for the sequence number used in BFD control packets. This document updates RFC 5880. "Unsolicited BFD for Sessionless Applications", Enke Chen, Naiming Shen, Robert Raszuk, Reshad Rahman, 2020-07-28, 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, 2020-11-02, 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) --------------------------------------- "BIER Use Cases", Nagendra Nainar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya, Caitlin Bestler, 2020-09-10, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes some of the use cases for BIER. "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Nagendra Nainar, Mach Chen, Santosh Pallagatti, 2020-11-15, This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow, 2020-11-19, 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, 2020-12-02, 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. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2020-09-08, This document defines a YANG data model for BIER configuration and operation. "BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, 2020-11-23, 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 information from the network, and the topology informations are used by the controller to calculate the fowarding table and then program 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 informations. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 2020-12-02, This document specifies protocols and procedures for forwarding broadcast, unknown unicast and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless Eckert, Gregory Cauchie, Michael Menth, 2020-10-30, This memo introduces per-packet stateless strict and loose path steered replication and forwarding for Bit Index Explicit Replication packets (RFC8279). This is called BIER Tree Engineering (BIER-TE). BIER-TE can be used as a path steering mechanism in future Traffic Engineering solutions for BIER (BIER-TE). BIER-TE leverages RFC8279 and extends it with a new semantic for bits in the bitstring. BIER-TE can leverage BIER forwarding engines with little or no changes. In BIER, the BitPositions (BP) of the packets bitstring indicate BIER Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a Routing Underlay such as an IGP. In BIER-TE, BitPositions indicate adjacencies. The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER- TE topology. The BIER-TE topology can consist of layer 2 or remote (routed) adjacencies. The BFR then replicates and forwards BIER packets to those adjacencies. This results in the aforementioned strict and loose path steering and replications. BIER-TE can co-exist with BIER forwarding in the same domain, for example by using separate BIER sub-domains. In the absence of routed adjacencies, BIER-TE does not require a BIER routing underlay, and can then be operated without requiring an Interior Gateway Routing protocol (IGP). BIER-TE operates without explicit in-network tree-state and carries the multicast distribution tree in the packet header. It can therefore 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, 2020-11-16, 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 BIER Domain toward the source. This draft explains the procedure to signal PIM joins and prunes through a BIER Domain, as such enable provisioning of traditional PIM services through a BIER Domain. "BIER Underlay Path Calculation Algorithm and Constraints", Zhaohui Zhang, Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands, Arkadiy Gulko, 2020-09-22, This document specifies general rules for interaction between the BAR (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ OSPFv2 Extensions for BIER. The semantics for the BAR and IPA fields (when both or any of them is non-zero) defined in this document updates the semantics defined in RFC 8401 and RFC 8444. "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", IJsbrand Wijnands, Mankamana Mishra, Xiaohu Xu, Hooman Bidgoli, 2020-11-26, 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. "Use of BIER Entropy for Data Center Clos Networks", Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride, 2020-10-27, Bit Index Explicit Replication (BIER) introduces a new multicast- specific BIER Header. BIER can be applied to the Multi Protocol Label Switching (MPLS) data plane or Non-MPLS data plane. Entropy is a technique used in BIER to support load-balancing. This document examines and describes how BIER Entropy is to be applied to Data Center Clos networks for path selection. "BIER Penultimate Hop Popping", Zhaohui Zhang, 2020-08-24, Bit Index Explicit Replication (BIER) can be used as provider tunnel for Multicast Virtual Private Network (MVPN). Global Table Multicast [RFC7716] or Ethernet Virtual Private Network (EVPN). It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER-incapable transit routers. However those methods assume the MVPN/EVPN Provider Edges (PEs) are BIER-capable. This document specifies a method to allow BIER- incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BIER Forwarding Router (BFR) that is connected directly or indirectly via a tunnel to a BIER-incapable PE remove the BIER header and send the payload to the PE. "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Dirk Trossen, Akbar Rahman, Chonggang Wang, Toerless Eckert, 2021-01-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 HLS, AR/VR, etc., 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. DVB and 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, Huanan Chen, 2020-08-12, 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, 2020-11-20, 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 IPv6 Requirements", Mike McBride, Jingrong Xie, Xuesong Geng, Senthil Dhanaraj, Rajiv Asati, Yongqing Zhu, Gyan Mishra, Zhaohui Zhang, 2020-09-28, There have been several proposed solutions with BIER being used in IPv6. But there hasn't been a document which describes the problem and lists the requirements. The goal of this document is to describe the general BIER IPv6 encapsulation problem and detail solution requirements, thereby assisting the working group in the development of acceptable solutions. "LSR Extensions for BIER over Ethernet", Senthil Dhanaraj, Gang Yan, IJsbrand Wijnands, Peter Psenak, Zhaohui Zhang, Jingrong Xie, 2020-12-02, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation. "BIER Prefix Redistribute", Zheng Zhang, Bo Wu, Zhaohui Zhang, IJsbrand Wijnands, Yisong Liu, 2020-08-04, This document defines a BIER proxy function to interconnect different underlay routing protocol areas in a network. And a new BIER proxy range sub-TLV is also defined to convey BIER BFR-id information across the routing areas. "Tethering A BIER Router To A BIER incapable Router", Zhaohui Zhang, Nils Warnke, IJsbrand Wijnands, Daniel Awduche, 2021-01-04, This document specifies optional procedures to optimize the handling of Bit Index Explicit Replication (BIER) incapable routers, by attaching (tethering) a BIER router to a BIER incapable router. "M-LDP Signaling Through BIER Core", Hooman Bidgoli, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang, Eddie Leyton, 2020-11-10, Consider an end to end Multipoint LDP (mLDP) network, where it is desirable to deploy BIER in portion of this network. It might be desirable to deploy BIER with minimum disruption to the mLDP network or redesign of the network. This document describes the procedure needed for mLDP tunnels to be signaled over and stitched through a BIER core, allowing LDP routers to run traditional mLDP services through a BIER core. "BIER BFD", Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, 2020-11-12, Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore Tiruveedhula, 2020-08-07, 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, 2020-10-30, This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), next-generation intrusion detection and prevention systems (NGIDS/NGIPS) and unified threat management (UTM) implementations. This document aims to strongly improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 application use cases. The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFW and NGIDS/NGIPS to start with. "Updates for the Back-to-back Frame Benchmark in RFC 2544", Alfred Morton, 2020-12-18, Fundamental Benchmarking Methodologies for Network Interconnect Devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-back frames Benchmark of RFC 2544, based on further experience. This memo updates Section 26.4 of RFC 2544. Calendaring Extensions (calext) ------------------------------- "Support for iCalendar Relationships", Michael Douglass, 2020-12-31, This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. "Event Publishing Extensions to iCalendar", Michael Douglass, 2021-01-13, This specification updates RFC5545 by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar RFC5545 to allow for data that is directly pertinent to an event or task to be included with the calendar data. "JSCalendar: A JSON representation of calendar data", Neil Jenkins, Robert Stepanek, 2020-10-15, This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. "JSCalendar: Converting from and to iCalendar", Neil Jenkins, Robert Stepanek, Michael Douglass, 2020-07-29, This document provides the required methods for converting JSCalendar from and to iCalendar. "Calendar subscription upgrades", Michael Douglass, 2020-07-29, 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. "VALARM Extensions for iCalendar", Cyrus Daboo, Kenneth Murchison, 2020-11-25, This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. This document updates RFC5545. "Support for Series in iCalendar", Michael Douglass, 2020-10-14, This document updates [RFC5545] by defining a new repeating set of events known as a series. This differs from recurrences in that each instance is a separate entity with a parent relationship to a specified template entity. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Cyrus Daboo, Michael Douglass, 2020-10-14, This specification introduces a new iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. "Serverside Subscriptions", Michael Douglass, 2020-07-28, This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates [RFC4791] to add new properties for the MKCOL request. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Concise Binary Object Representation (CBOR) Tags for Object Identifiers", Carsten Bormann, Sean Leonard, 2020-11-17, The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 7049bis) 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. The present document defines CBOR tags for object identifiers (OIDs). It is intended as the reference document for the IANA registration of the CBOR tags so defined. "Additional Control Operators for CDDL", Carsten Bormann, 2020-11-17, 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 did not make it into RFC 8610: ".cat"/".plus" 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, 2020-09-30, The Concise Binary Object Representation (CBOR, RFC 7049) 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) work well for CBOR, 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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation", Giovanni Martinelli, Haomian Zheng, Gabriele Galimberti, Young Lee, Fatai Zhang, 2020-09-07, This document defines an information model to support Impairment- Aware (IA) Routing and Wavelength Assignment (RWA) functionality. This information model extends the information model for impairment- free RWA process in WSON to facilitate computation of paths where optical impairment constraints need to considered. "A YANG Data Model for WSON (Wavelength Switched Optical Networks)", Haomian Zheng, Young Lee, Aihua Guo, Victor Lopez, Daniel King, 2020-12-29, This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in wavelength switched optical networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). "A YANG Data Model for Optical Transport Network Topology", Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios, 2020-09-21, 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, 2020-09-18, This document describes the YANG data model for OTN Tunnels. "A YANG Data Model for Flexi-Grid Optical Networks", Universidad de Madrid, Daniel Perdices, Daniel King, Young Lee, Haomian Zheng, 2020-11-01, This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. A partner document defines a second YANG module for flexi-grid media channels, i.e., the paths from source to destination through a number of intermediate nodes. "Transport Northbound Interface Applicability Statement", Italo Busi, Daniel King, Haomian Zheng, Yunbin Xu, 2021-01-04, 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, 2020-11-02, 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. "Applicability of GMPLS for B100G Optical Transport Network", Qilei Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti, 2020-12-07, 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, 2020-11-18, 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, 2020-11-18, 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, Luc Auge, Victor Lopez, Gabriele Galimberti, Dieter Beller, 2020-11-02, 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 Layer 0 Types", Haomian Zheng, Young Lee, Aihua Guo, Victor Lopez, Daniel King, 2020-12-29, This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and Flexi-grid Dense Wavelength Division Multiplexing (DWDM) Networks. "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-01-13, 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, 2020-11-02, 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. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, Phil Sorber, 2019-10-08, This document describes how the concept of URI signing supports the content access control requirements of 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 UA. The mechanism described can be used both in CDNI and single CDN scenarios. "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile, Sanjay Mishra, 2020-09-09, 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, 2020-12-23, 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 0, 1, and 3", Michael Niedermayer, Dave Rice, Jerome Martinez, 2020-12-01, 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. "FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice, Jerome Martinez, 2020-12-01, 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, 2020-10-19, 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, 2020-10-19, 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, 2020-10-19, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. Crypto Forum (cfrg) ------------------- "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2021-01-17, This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key with no risk of 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. "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2020-09-08, This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. 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, 2020-11-18, 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, 2020-10-11, 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, 2020-12-16, This document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides authenticated public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. 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, 2020-11-02, 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", Benoit Viguier, David Wong, Giles Van Assche, Quynh Dang, Joan Daemen, 2020-09-21, This document defines the KangarooTwelve eXtendable Output Function (XOF), a hash function with output of arbitrary length. It provides an efficient and secure hashing primitive, which is able to exploit the parallelism of the implementation in a scalable way. It uses tree hashing over a round-reduced version of SHAKE128 as underlying primitive. This document builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. "BLS Signatures", Dan Boneh, Sergey Gorbunov, Riad Wahby, Hoeteck Wee, Zhenfei Zhang, 2020-09-10, BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. "Pairing-Friendly Curves", Yumi Sakemi, Tetsutaro Kobayashi, Tsunekazu Saito, Riad Wahby, 2020-11-16, 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, 2020-07-28, 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, 2020-09-20, 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-user settings. "The OPAQUE Asymmetric PAKE Protocol", Hugo Krawczyk, Kevin Lewi, Christopher Wood, 2020-11-02, 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, along with several instantiations in different authenticated key exchange protocols. "The ristretto255 and decaf448 Groups", Henry de Valence, Jack Grigg, George Tankersley, Filippo Valsorda, Isis Lovecruft, Mike Hamburg, 2020-10-05, 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. Computing in the Network Research Group (coinrg) ------------------------------------------------ "Use Cases for In-Network Computing", Ike Kunze, Klaus Wehrle, Dirk Trossen, 2020-11-02, Computing in the Network (COIN) comes with the prospect of deploying functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial in several contexts, it has to be carefully placed into the context of the general Internet communication. This document discusses some use cases to demonstrate how real applications can benefit from COIN and to showcase essential requirements that have to be fulfilled by COIN applications. "Directions for Computing in the Network", Dirk Kutscher, Teemu Karkkainen, Joerg Ott, 2020-07-31, In-network computing can be conceived in many different ways - from active networking, data plane programmability, running virtualized functions, service chaining, to distributed computing. This memo proposes a particular direction for Computing in the Networking (COIN) research and lists suggested research challenges. Constrained RESTful Environments (core) --------------------------------------- "CoRE Resource Directory", Christian Amsuess, Zach Shelby, Michael Koster, Carsten Bormann, Peter van der Stok, 2020-11-02, 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, 2021-01-17, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 7049). "Dynamic Resource Linking for Constrained RESTful Environments", Michael Koster, Bill Silverajan, 2021-01-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). This specification also defines Conditional Notification and Control Attributes that work with Link Bindings or with CoAP Observe (RFC7641). 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, 2021-01-17, 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 Management Interface (CORECONF)", Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Ivaylo Petrov, 2021-01-17, This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. "CoAP: Echo, Request-Tag, and Token Processing", Christian Amsuess, John Mattsson, Goeran Selander, 2020-11-02, 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 RFC7252 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, Jiye Park, 2020-11-02, 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. "Uniform Resource Names for Device Identifiers", Jari Arkko, Cullen Jennings, Zach Shelby, 2021-01-13, This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be passed along in applications that need the information. "Constrained YANG Module Library", Michel Veillette, Ivaylo Petrov, 2021-01-11, This document describes a constrained version of the YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a constrained network management server (e.g., a CORECONF server). "SenML Data Value Content-Format Indication", Ari Keranen, Carsten Bormann, 2021-01-15, 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 simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. "Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP", Ilpo Jarvinen, Markku Kojo, Iivo Raitahila, Zhen Cao, 2020-10-19, This document specifies an alternative retransmission timeout and congestion control back off algorithm for the CoAP protocol, called Fast-Slow RTO (FASOR). The algorithm specified in this document employs an appropriate and large enough back off of Retransmission Timeout (RTO) as the major congestion control mechanism to allow acquiring unambiguous RTT samples with high probability and to prevent building a persistent queue when retransmitting. The algorithm also aims to retransmit quickly using an accurately managed retransmission timeout when link- errors are occuring, basing RTO calculation on unambiguous round-trip time (RTT) samples. "Group Communication for the Constrained Application Protocol (CoAP)", Esko Dijk, Chonggang Wang, Marco Tiloca, 2020-11-02, This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, using UDP/IP multicast as the 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 networks. The most common of such use cases are also discussed. This document replaces [RFC7390] and updates [RFC7252] and [RFC7641]. "SenML Features and Versions", Carsten Bormann, 2020-11-15, This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. "Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission", Mohamed Boucadair, Jon Shallow, 2021-01-19, This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable 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. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE): Structures and Process", 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 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, 2020-12-16, 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. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", Mark Baushke, 2021-01-14, 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) Security Considerations", Ethan Grossman, Tal Mizrahi, Andrew Hacker, 2020-12-11, A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e. "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties. This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a threat model, taxonomy of relevant attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival time violation detection. This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents. "DetNet Flow Information Model", Balazs Varga, Janos Farkas, Rodney Cummings, Yuanlong Jiang, Don Fedyk, 2020-12-13, This document describes flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes "Deterministic Networking (DetNet) Configuration YANG Model", Xuesong Geng, Mach Chen, Yeoncheol Ryoo, Don Fedyk, Reshad Rahman, Zhenqiang Li, 2020-11-16, This document contains the specification for Deterministic Networking flow configuration YANG Model. The model allows for provisioning of end-to-end DetNet service along the path without dependency on any signaling protocol. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, Don Fedyk, 2020-12-13, This document specifies the Deterministic Networking data plane when TSN networks are interconnected over a DetNet MPLS Network. "DetNet Data Plane: MPLS over UDP/IP", Balazs Varga, Janos Farkas, Lou Berger, Andrew Malis, Stewart Bryant, 2020-12-14, This document specifies the MPLS Deterministic Networking data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-in-UDP technology. "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2020-12-13, This document specifies the Deterministic Networking MPLS data plane when operating over a TSN sub-network. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2020-12-13, This document specifies the Deterministic Networking IP data plane when operating over a TSN sub-network. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. "DetNet Data Plane: IP over MPLS", Balazs Varga, Lou Berger, Don Fedyk, Stewart Bryant, Jouni Korhonen, 2020-10-11, This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet switched network. "DetNet Bounded Latency", Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas, 2020-10-30, This document presents a timing model for Deterministic Networking (DetNet), so that existing and future standards can achieve the DetNet quality of service features of bounded latency and zero congestion loss. It defines requirements for resource reservation protocols or servers. It calls out queuing mechanisms, defined in other documents, that can provide the DetNet quality of service. "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane", Greg Mirsky, Mach Chen, 2021-01-15, 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-01-15, This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. Dynamic Host Configuration (dhc) -------------------------------- "YANG Data Model for DHCPv6 Configuration", Yong Cui, Linhui Sun, Ian Farrer, Sladjana Zechlin, Zihao He, Michal Nowikowski, 2021-01-07, This document describes YANG data modules for the configuration and management of DHCPv6 servers, relays, and clients. "DHCPv6 Extension Practices and Considerations", Ren Gang, Lin He, Ying Liu, 2020-11-15, IP addresses as the communication identifier bear more and more properties to meet different requirements. The privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol according to requirements. This document provides current extension practices and typical DHCPv6 server softwares on extensions, defines a DHCPv6 general model, discusses some extension points, and presents extension cases. "DHCPv6 Prefix Delegating Relay Requirements", Ian Farrer, Naveen Kottapalli, Martin Hunek, Richard Patterson, 2021-01-04, This document describes operational problems that are known to occur when using DHCPv6 relays with Prefix Delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with Prefix Delegation. It is recommended that any network operator that is using DHCPv6 prefix delegation with relays should ensure that these requirements are followed on their networks. 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. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)", Scott Kitterman, 2020-09-22, DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. "DMARC Use of the RFC5322.Sender Header Field", Dave Crocker, 2020-09-25, Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message. The RFC5322.Sender field is optional, if it has the same information as the RFC5322.From field. That is, when the RFC5322.Sender field is absent, the RFC5322.From field has conflated semantics, with both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the RFC5322.From field has become dominated by its role as a handling identifier. The current specification augments use of the RFC5322.From field, by enhancing DMARC to also use the RFC5322.Sender field. This preserves the utility of RFC5322.From field while also preserving the utility of DMARC. "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Emil Gustafsson, Todd Herr, John Levine, 2020-11-11, This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. Mail-receiving organizations can in turn use these expressions of policies and preferences to inform their mail handling decisions should they choose to do so. This document obsoletes RFC 7489. "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting", Steven Jones, Alessandro Vesely, 2020-11-11, Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports," which provide details about individual messages that failed to authenticate according to the DMARC mechanism. "DMARC Aggregate Reporting", Alex Brotman, 2020-11-12, 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) ------------------------------------- "Protocol for Forwarding Policy Configuration (FPC) in DMM", Satoru Matsushima, Lyle Bertz, Marco Liebsch, Sri Gundavelli, Danny Moses, Charles Perkins, 2020-09-22, This document describes a way, called Forwarding Policy Configuration (FPC) to manage the separation of data-plane and control-plane. FPC defines a flexible mobility management system using FPC agent and FPC client functions. A FPC agent provides an abstract interface to the data-plane. The FPC client configures data-plane nodes by using the functions and abstractions provided by the FPC agent for the data- plane nodes. The data-plane abstractions presented in this document are extensible in order to support many different types of mobility management systems and data-plane functions. "User Plane Protocol and Architectural Analysis on 3GPP 5G System", Shunsuke Homma, Takuya Miyasaka, Satoru Matsushima, Daniel Voyer, 2020-11-02, This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. Domain Name System Operations (dnsop) ------------------------------------- "DNS Query Name Minimisation to Improve Privacy", Stephane Bortzmeyer, Ralph Dolmans, Paul Hoffman, 2020-10-27, 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. This document is part of the IETF DNSOP (DNS Operations) Working Group. The source of the document, as well as a list of open issues, is at "Message Digest for DNS Zones", Duane Wessels, Piet Barber, Matt Weinberg, Warren Kumari, Wes Hardaker, 2020-10-15, This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. "Terminology for DNS Transports and Location", Paul Hoffman, 2020-08-03, This document adds terms and abbreviations to "DNS Terminology" (RFC 8499) that relate to DNS running over various transports, as well as terms and abbreviations for DNS resolution at traditional and non- traditional locations. "Interoperable Domain Name System (DNS) Server Cookies", Ondrej Sury, Willem Toorop, Donald Eastlake, Mark Andrews, 2021-01-13, DNS Cookies, as specified in [RFC7873], are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of amplification denial of service, forgery, or cache poisoning attacks by off-path attackers. This document updates [RFC7873] with precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, suggestions for constructing Client Cookies in a privacy preserving fashion, and suggestions on how to update a Server Secret. An IANA registry listing the methods and associated pseudo random function suitable for creating DNS Server Cookies is created, with the method described in this document as the first and as of yet only entry. "YANG Types for DNS Classes and Resource Record Types", Ladislav Lhotka, Petr Spacek, 2020-11-14, This document introduces the YANG module "iana-dns-class-rr-type" that contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as a minimum basis for future data modeling work. "DNS TIMEOUT Resource Record", Tom Pusateri, Tim Wattenberg, 2020-07-25, This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records. It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts. "DNS Catalog Zones", Peter van Dijk, Libor Peltan, Ondrej Sury, Willem Toorop, Leo Vandewoestijne, 2020-12-04, 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. "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2020-11-02, 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 HTTPS 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 HTTPS and HTTP origins. 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 [1]. 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, 2020-11-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, 2020-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, 2020-09-08, 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. "Top-level Domains for Private Internets", Roy Arends, Joe Abley, 2020-10-08, There are no defined private-use namespaces in the Domain Name System (DNS). For a domain name to be considered private-use, it needs to be future-proof in that its top-level domain will never be delegated from the root zone. The lack of a private-use namespace has led to locally configured namespaces with a top-level domain that is not future proof. The DNS needs an equivalent of the facilities provided by BCP 5 (RFC 1918) for private internets, i.e. a range of short, semantic-free top-level domains that can be used in private internets without the risk of being globally delegated from the root zone. The ISO 3166 standard is used for the definition of eligible designations for country-code top-level Domains. This standard is maintained by the ISO 3166 Maintenance Agency. The ISO 3166 standard includes a set of user-assigned code elements that can be used by those who need to add further names to their local applications. Because of the rules set out by ISO in their standard, it is extremely unlikely that these user-assigned code elements would ever conflict with delegations in the root zone under current practices. This document explicitly reserves these code elements to be safely used as top-level domains for private DNS resolution. "DNS Terminology", Paul Hoffman, Kazunori Fujiwara, 2020-11-20, 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. "NSEC(3) TTLs and NSEC Aggressive Use", Peter van Dijk, 2021-01-13, Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC(3) records may deny names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC(3) TTL to correct that situation. This document updates RFC 4034, RFC 4035, and RFC 5155. "Revised IANA Considerations for DNSSEC", Paul Hoffman, 2021-01-22, This document changes the review requirements needed to get some DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms. It also 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. Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "Service Registration Protocol for DNS-Based Service Discovery", Ted Lemon, Stuart Cheshire, 2021-01-11, 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. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2020-07-05, The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Mohamed Boucadair, Tirumaleswar Reddy.K, Wei Pan, 2020-11-23, 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. "Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", Kaname Nishizuka, Mohamed Boucadair, Tirumaleswar Reddy.K, Takahiko Nagata, 2020-06-25, This document specifies an extension to the Distributed Denial-of- Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de- activate existing filtering rules during a DDoS attack. The characterization of these filtering rules is conveyed by a DOTS client during an idle time (i.e., no mitigation is active) by means of the DOTS data channel protocol. 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: Controlling Filtering Rules Using Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update the "revision" date of the YANG module. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home", Tirumaleswar Reddy.K, Mohamed Boucadair, Jon Shallow, 2021-01-11, 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, 2020-12-08, 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. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Mohamed Boucadair, Jon Shallow, Tirumaleswar Reddy.K, 2020-12-03, This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. This document obsoletes RFC 8782. "Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", Yuhei Hayashi, chenmeiling, Li Su, 2020-11-18, 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. DNS PRIVate Exchange (dprive) ----------------------------- "DNS Privacy Considerations", Tim Wicinski, 2020-10-16, This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. "DNS Zone Transfer-over-TLS", Willem Toorop, Sara Dickinson, Shivan Sahib, Pallavi Aras, Allison Mankin, 2021-01-20, DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of TLS, rather then clear text, to prevent zone content collection via passive monitoring of zone transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. "DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers", Jason Livingood, Alexander Mayrhofer, Benno Overeinder, 2020-11-02, This document describes requirements and considerations for adding confidentiality to DNS exchanges between recursive resolvers and authoritative servers. The intent of this document is to guide Internet Drafts in the DNS Private Exchange (DPRIVE) Working Group pertaining to recursive to authorized name servers, with the stated requirements and considerations. "Specification of DNS over Dedicated QUIC Connections", Christian Huitema, Allison Mankin, Sara Dickinson, 2020-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 error corrections 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. Drone Remote ID Protocol (drip) ------------------------------- "Drone Remote Identification Protocol (DRIP) Requirements", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Andrei Gurtov, 2020-11-01, This document defines terminology and requirements for Drone Remote Identification Protocol (DRIP) Working Group protocols to support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety and other purposes. Complementing external technical standards as regulator-accepted means of compliance with UAS RID regulations, DRIP will: facilitate use of existing Internet resources to support UAS RID and to enable enhanced related services; enable online and offline verification that UAS RID information is trustworthy. "Drone Remote Identification Protocol (DRIP) Architecture", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Shuai Zhao, Andrei Gurtov, 2021-01-21, This document defines an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus RID-related communications, including required architectural building blocks and their interfaces. "UAS Remote ID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2020-12-31, 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 UAS Remote ID. HHITs self-attest to the included explicit hierarchy that provides Registrar discovery for 3rd-party ID attestation. "DRIP Authentication Formats", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2020-12-18, 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, 2020-12-10, 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-01-08, 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, 2020-12-07, 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, 2020-11-01, This document defines default integrity and confidentiality security contexts that may be used with the Bundle Protocol Security Protocol (BPSec) implementations. These security contexts may 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) --------------------------------------------------------------- "Changing the LoST Location Profile Registry Policy", Randall Gellens, 2020-11-18, This document changes the policy of the Location-to-Service Translation (LoST) Location Profile registry established by RFC5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. Revision of core Email specifications (emailcore) ------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 2020-12-25, 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 as an Internet Standard.]] "Applicability Statement for IETF Core Email Protocols", John Klensin, 2020-10-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, 2020-10-06, 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", John Mattsson, Mohit Sethi, 2020-11-19, This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP- TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further improves security and privacy by mandating use of privacy and revocation checking. This document also provides guidance on 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-01-11, 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 memo 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. "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", Jari Arkko, Karl Norrman, Vesa Torvinen, 2020-10-30, Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. "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, 2020-12-13, 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 an 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, 2020-07-29, 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) --------------------------------------------------------- "Internet Message Access Protocol (IMAP) - Version 4rev2", Alexey Melnikov, Barry Leiba, 2021-01-20, The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. "IMAP QUOTA Extension", Alexey Melnikov, 2020-11-17, The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. "Sieve Email Filtering: delivery by mailboxid", Bron Gondwana, 2020-12-03, The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. "Sieve Email Filtering: Snooze Extension", Kenneth Murchison, Ricardo Signes, Neil Jenkins, 2020-08-10, This document describes the "snooze" extension to the Sieve email filtering language. The "snooze" extension gives Sieve the ability to postpone the filing of an incoming into a target mailbox until a later point in time. Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- "Grant Negotiation and Authorization Protocol", Justin Richer, Aaron Parecki, Fabien Imbault, 2021-01-06, 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. Global Routing Operations (grow) -------------------------------- "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2021-01-14, The BGP Monitoring Protocol (BMP) defines access to various 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, 2020-10-26, 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, Henk Smit, 2020-11-16, 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, 2020-11-01, 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,to the internet community, with how best to utilize AS Path Prepending in order to avoid negatively affecting the internet. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu, 2019-02-14, This memo describes the Host Identity (HI) namespace, that provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The section on security considerations describe also measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers and trust on first use. This document incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, Miika Komu, 2020-08-03, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP. "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, Miika Komu, 2021-01-19, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and specifically developed for use on low end processors. The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and cryptographic hash functions. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. Unlike HIPv2, HIP DEX does not support Forward Secrecy (FS), and MUST only be used on devices where FS is prohibitively expensive. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. Home Networking (homenet) ------------------------- "Simple Provisioning of Public Names for Residential Networks", Daniel Migault, Ralf Weber, Michael Richardson, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2020-11-02, Home owners often have IPv6 devices that they wish to access over the Internet using names. 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, whose responsibility is to select, sign and publish names to a set of publically visible servers. The use of an outsourced primary DNS server deals with possible renumbering of the home network, and with possible denial of service attacks against the DNS infrastructure. This document describes the mechanism that enables the Home Network Authority (HNA) to outsource the naming service to the DNS Outsourcing Infrastructure via a Distribution Master (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, Chris Griffiths, Wouter Cloetens, 2020-10-22, This document defines DHCPv6 options so any agnostic Homnet 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. "Homenet profile of the Babel routing protocol", Juliusz Chroboczek, 2018-07-18, This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Guidelines for Human Rights Protocol and Architecture Considerations", Gurshabad Grover, Niels ten Oever, 2020-11-02, This document sets guidelines for human rights considerations in networking protocols, 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]. "Freedom of Association on the Internet", Niels ten Oever, Gisela de Acha, Stephane Couture, Mallory Knodel, 2020-11-01, This document discusses the relationships between the Internet architecture and the ability of people to exercise their right to freedom of assembly and association online. The Internet increasingly mediates our lives, our relationships, and our ability to exercise our human rights. As a global forum, the Internet provides a public space, yet it is predominantly built on private infrastructure. Since Internet protocols play a central role in the management, development, and use of the Internet, we analyze the relation between protocols and the rights to assemble and associate to mitigate infringements on those rights. Building Blocks for HTTP APIs (httpapi) --------------------------------------- "RateLimit Header Fields for HTTP", Roberto Polli, Alex Ruiz, 2020-12-18, This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields for HTTP, thus allowing servers to publish current request quotas and clients to shape their request policy and avoid being throttled out. "The Deprecation HTTP Header Field", Sanjay Dalal, Erik Wilde, 2020-12-25, 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-01-14, This specification defines two document formats and respective media types for representing sets of links as stand-alone resources. 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. HTTP (httpbis) -------------- "HTTP SEARCH Method", Julian Reschke, Ashok Malhotra, James Snell, 2020-09-02, This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. "HTTP Client Hints", Ilya Grigorik, Yoav Weiss, 2020-07-03, HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." "Cookies: HTTP State Management Mechanism", Mike West, John Wilander, 2020-12-07, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. "Structured Field Values for HTTP", Mark Nottingham, Poul-Henning Kamp, 2020-06-03, This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. "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. "HTTP Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 2021-01-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-01-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-01-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 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-01-13, To aid debugging, HTTP caches often append header fields to a response explaining how they handled the request. This specification codifies that practice and updates it to align with HTTP's current caching model. "The Proxy-Status HTTP Response Header Field", Mark Nottingham, Piotr Sikora, 2020-08-11, This document defines the Proxy-Status HTTP field to convey the details of intermediary handling of responses, including generated errors. "Digest Headers", Roberto Polli, Lucas Pardue, 2020-10-17, This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the exchanged resource representation data. This document obsoletes RFC 3230. It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. "Extensible Prioritization Scheme for HTTP", Kazuho Oku, Lucas Pardue, 2021-01-11, 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. "Signing HTTP Messages", Annabelle Backman, Justin Richer, Manu Sporny, 2020-11-17, This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over content within 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. 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. "Software-Defined Networking (SDN)-based IPsec Flow Protection", Rafael Marin-Lopez, Gabriel Lopez-Millan, Fernando Pereniguez-Garcia, 2020-10-30, This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) controller. It considers two main well- known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (SAs) from a I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic. The document focuses on the I2NSF NSF-facing interface by providing YANG data models for configuring the IPsec databases (SPD, SAD, PAD) and IKEv2. This allows IPsec SA establishment with minimal intervention by the network administrator. It does not define any new protocol. "I2NSF Consumer-Facing Interface YANG Data Model", Jaehoon Jeong, Chaehong Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2020-09-08, 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 [I-D.ietf-i2nsf-capability], 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, 2020-08-28, 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-01-17, 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, 2020-08-29, 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 YANG Data Model", Jaehoon Jeong, Patrick Lingga, Susan Hares, Liang Xia, Henk Birkholz, 2020-09-07, This document proposes an information model and the corresponding YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed 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 monitoring NSFs along with a YANG data diagram, but also the corresponding YANG data model for monitoring NSFs. Internet Architecture Board (iab) --------------------------------- "Report from the IAB workshop on Design Expectations vs. Deployment Reality in Protocol Development", Jari Arkko, Ted Hardie, 2020-11-02, The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration. IANA (iana) ----------- "Nameservers for the Address and Routing Parameter Area ("arpa") Domain", Kim Davies, Jari Arkko, 2021-01-04, 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. Internet Congestion Control (iccrg) ----------------------------------- "rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP", Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen Balasubramanian, 2020-08-26, This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. "LEDBAT++: Congestion Control for Background Traffic", Praveen Balasubramanian, Osman Ertugay, Daniel Havey, 2020-08-25, This informational memo describes LEDBAT++, a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. LEDBAT++ has been implemented as a TCP congestion control algorithm in the Windows operating system. LEDBAT++ has been deployed in production at scale on a variety of networks and been experimentally verified to achieve the original stated goals of LEDBAT. Information-Centric Networking (icnrg) -------------------------------------- "Native Deployment of ICN in LTE, 4G Mobile Networks", Prakash suthar, Milan Stolic, Anil Jangam, Dirk Trossen, Ravi Ravindran, 2020-07-25, LTE, 4G mobile networks use 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 transport used in the user plane is not optimized for data transport, which leads to inefficient data delivery. For instance, IP unicast routing from server to clients is used for the delivery of multimedia content to User Equipment (UE), with each user receiving a separate stream. From a bandwidth and routing perspective, this approach is inefficient. Multicast and broadcast technologies have recently emerged for mobile networks, but their deployments are very limited or at an experimental stage. ICN is a rapidly emerging technology, although much of the work is focused on fixed networks. The focus of this draft is on native deployment of ICN in cellular mobile networks by using ICN in a 3GPP protocol stack. ICN has inherent capabilities for multicast, anchorless mobility, and security, while being optimized for data delivery using local caching at the edge. The proposed approaches in this draft allow ICN to be enabled natively over the current LTE stack comprising PDCP/RLC/MAC/PHY, or in a dual stack mode (alongside IP). This document is a product of the Information-Centric Networking Research Group (ICNRG). "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Hitoshi Asaeda, Atsushi Ooka, Xun Shao, 2020-09-21, 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. "Design Considerations for Name Resolution Service in ICN", Jungha Hong, Taewan You, Lijun Dong, Cedric Westphal, Borje Ohlman, 2020-10-09, 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, 2020-09-09, 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, 2020-10-30, 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). "Considerations in the development of a QoS Architecture for CCNx-like ICN protocols", David Oran, 2020-11-19, This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in ICN protocols like CCNx or NDN which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP, and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU and link bandwidth as a resource that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve both transport and higher layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE) which can only be assessed and controlled at the application layer or above. This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal last call and has the support of the participants in the research group for publication as an individual submission. "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Ravi Ravindran, Prakash suthar, Dirk Trossen, Chonggang Wang, Greg White, 2021-01-10, The proposed 3GPP's 5G core nextgen architecture (5GC) allows the introduction of new user and control plane function, considering the support for network slicing functions, that offers greater flexibility to handle heterogeneous devices and applications. In this draft, we provide a short description of the proposed 5GC architecture, including recent efforts to provide cellular Local Area Network (LAN) connectivity, followed by extensions to 5GC's control and user plane to support Packet Data Unit (PDU) sessions over Information-Centric Networks (ICN). In addition, ICN over 5GLAN is also described. "ICN Ping Protocol Specification", Spyridon Mastorakis, Jim Gibson, Ilya Moiseenko, Ralph Droms, David Oran, 2020-10-08, This document presents the design of an ICN Ping protocol. It includes the operations of both the client and the forwarder. "ICN Traceroute Protocol Specification", Spyridon Mastorakis, Jim Gibson, Ilya Moiseenko, Ralph Droms, David Oran, 2020-10-10, This document presents the design of an ICN Traceroute protocol. This includes the operation of both the client and the forwarder. Inter-Domain Routing (idr) -------------------------- "Extended Optional Parameters Length for BGP OPEN Message", Enke Chen, John Scudder, 2020-08-21, The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we update RFC 4271 by extending, in a backward- compatible manner, the length of the Optional Parameters in the BGP OPEN. The Parameter Length field of individual Optional Parameters is also extended. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Kevin Wang, 2021-01-15, This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best path from the standpoint of their clients, rather than from the standpoint of the route reflectors. Multiple types of granularity are proposed, from a per client BGP route selection or to a per peer group, depending on the scaling and precision requirements on route selection. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector IGP location is suboptimal. This facilitates, for example, best exit point policy (hot potato routing). The solution relies upon all route reflectors learning all paths which are eligible for consideration. Best path selection is performed in each route reflector based on the IGP cost from a selected location in the link state IGP. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra, 2020-07-08, This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. This document updates RFC5575bis. "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, 2020-10-23, 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. "Performance-based BGP Routing Mechanism", Xiaohu Xu, Shraddha Hegde, Ketan Talaulikar, Mohamed Boucadair, Christian Jacquenet, 2020-12-22, The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang, 2020-11-16, This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/SAFI 6/133 and 25/134 are used for these purposes. New component types and an extended community also are defined. "Distribution of Traffic Engineering Extended Admin Groups using BGP-LS", Zitao Wang, Qin WU, Jeff Tantsura, Ketan Talaulikar, 2020-11-15, Administrative groups are link attributes (commonly referred to as "colors" or "link colors") advertised by link state protocols (e.g. ISIS or OSPF) and used for traffic engineering. These administrative groups were initially defined as 32 bit masks. As network usage grew, these 32 bit masks were found to constrain traffic engineering. Therefore, link state protocols (ISIS, OSPF) were expanded to advertise a variable length administrative group. "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Keyur Patel, Saikat Ray, Jie Dong, 2019-05-16, Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to BGP Link-State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Christoph Dietzel, 2020-09-21, When BGP route servers are used, the data plane is not congruent with the control plane. Therefore, peers at an Internet exchange can lose data connectivity without the control plane being aware of it, and packets are lost. This document proposes the use of a newly defined BGP Subsequent Address Family Identifier (SAFI) both to allow the route server to request its clients use BFD to track data plane connectivity to their peers' addresses, and for the clients to signal that connectivity state back to the route server. "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas, 2020-11-15, 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. "The BGP Tunnel Encapsulation Attribute", Keyur Patel, Gunter Van de Velde, Srihari Sangli, John Scudder, 2021-01-07, This document defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute", which can be used with BGP UPDATEs of various SAFIs to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of Tunnel Types along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation Attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation Attribute where load balancing is desired. "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2020-12-02, This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 5575bis) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. "BGP Link-State extensions for Segment Routing", Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen, 2019-06-27, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This document defines extensions to the BGP Link-state address-family in order to carry segment routing information via BGP. "BGP Next-Hop dependent capabilities", Bruno Decraene, Kireeti Kompella, Wim Henderickx, 2020-10-06, RFC 5492 advertises the capabilities of the BGP peer. When the BGP peer is not the same as the BGP Next-Hop, it is useful to also be able to advertise the capability of the BGP Next-Hop, in particular to advertise forwarding plane features. This document defines a mechanism to advertise such BGP Next Hop dependent Capabilities. This document defines a new BGP non-transitive attribute to carry Next-Hop Capabilities. This attribute is guaranteed to be deleted or updated when the BGP Next Hop is changed, in order to reflect the capabilities of the new BGP Next-Hop. This document also defines a Next-Hop capability to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard to this BGP signaling. "Route Leak Prevention using Roles in Update and Open messages", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Kotikalapudi Sriram, 2021-01-16, Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one lateral peer to another lateral peer or a transit provider, passing a route learned from one transit provider to another transit provider or a lateral peer. 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 BGP OPEN to establish agreement of the (peer, customer, provider, Route Server, Route Server client) relationship of two neighboring eBGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an Only to Customer (OTC) attribute 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, 2020-11-14, This document defines a new BGP SAFI with a new NLRI in order 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 a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which 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. "Signaling Maximum Transmission Unit (MTU) using BGP-LS", Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair, 2020-11-17, 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-LS Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, 2020-09-28, 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 Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Bruno Decraene, 2020-11-14, Segment Routing (SR) 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 the various protocols such as BGP, IS-IS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS data-plane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with their behaviors and other attributes via BGP. "Application-Specific Attributes Advertisement with BGP Link-State", Ketan Talaulikar, Peter Psenak, Jeff Tantsura, 2020-11-14, 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, 2020-11-14, 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, 2020-11-14, 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, 2020-09-09, 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, 2020-11-02, In a number of environments, a component external to a network is called upon to perform computations based on the network topology and 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 a number of small changes and clarifications to the previous specification. "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu, 2020-11-01, 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, Huanan Chen, Weiqiang Cheng, Ketan Talaulikar, 2020-11-02, 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, 2020-11-23, 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. "Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries", Adrian Farrel, 2020-12-09, RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS). IANA created a registry consistent with that document called the "Border Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a number of sub-registries. The allocation policy applied by IANA for those registries is "Specification Required" as defined in RFC 8126. This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the Designated Experts. "Segment Routing Path MTU in BGP", Cheng Li, Yongqing Zhu, Ahmed El Sawaf, Zhenbin Li, 2020-11-01, 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, 2020-07-31, 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, 2020-11-19, 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, 2020-11-19, 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. Internet Area Working Group (intarea) ------------------------------------- "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2019-10-26, This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. 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, 2020-11-22, 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 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, IPv6 (via extension header), or IPv4. 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, 2020-10-07, 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, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel, Suresh Krishnan, Rajiv Asati, Mark Smith, 2020-11-01, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6. "In-situ OAM Flags", Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel, Jennifer Lemon, 2020-10-26, 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 presents new flags in the IOAM Trace Option headers. Specifically, the document defines the Loopback and Active flags. "Metrics and Methods for One-way IP Capacity", Alfred Morton, Ruediger Geib, Len Ciavattone, 2020-09-10, 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, 2020-11-01, 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 without being pushed into in-flight data packets. "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2020-12-23, 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-01-12, 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. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "IKEv2 Notification Status Types for IPv4/IPv6 Coexistence", Mohamed Boucadair, 2020-12-17, This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence by allowing the responder to signal to the initiator which address families are allowed. This document updates RFC7296. "Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana Prasad, 2020-10-30, 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, 2020-09-10, 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: IP Traffic Flow Security Using Aggregation and Fragmentation", Christian Hopps, 2021-01-19, This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality 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-01-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-01-10, 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 Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Jaehoon Jeong, 2020-07-29, 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 lists up requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking. JSON Mail Access Protocol (jmap) -------------------------------- "Handling Message Disposition Notification with JMAP", Raphael Ouazana, 2020-12-10, This document specifies a data model for handling Message Disposition Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621). "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2020-07-26, This document specifies a data model for synchronizing calendar data with a server using JMAP. "JSContact: A JSON representation of contact data", Robert Stepanek, Mario Loffredo, 2020-12-14, 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, 2020-10-11, This document provides informational guidance for converting the contact card defined by JSContact specification, namely JSCard, from and to vCard. "JMAP for Sieve Scripts", Kenneth Murchison, 2020-12-17, This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). JSON Path (jsonpath) -------------------- "JavaScript Object Notation (JSON) Path", Glyn Normington, Edward Surov, Marko Mikulicic, Stefan Gossner, 2020-12-07, JSONPath defines a string syntax for identifying values within a JavaScript Object Notation (JSON) document. Note *This document is a work in progress and has not yet been published as an Internet Draft* (which needs to be fixed soon). 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 can be directed at the github repository _insert repo here_ as well as (for the time when the more permanent home is being decided) at the dispatch@ietf.org mailing list. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 2019-08-28, 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 to facilitate an extensible authentication model. 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, 2020-11-22, 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, 2020-11-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. Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John Mattsson, Francesca Palombini, 2020-12-18, 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, perfect 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-01-22, 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, adding new general message types, defining extended key usages to identify certificates of CMP endpoints on certification and registration authorities, and adding an HTTP URI discovery mechanism and extending the URI structure. 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. "Lightweight CMP Profile", Hendrik Brockhaus, Steffen Fries, David von Oheimb, 2020-11-02, The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2, the related Certificate Request Message Format (CRMF) version 2, and the HTTP Transfer for the Certificate Management Protocol. It specifies a subset of CMP and CRMF focusing on typical use cases relevant for managing certificates of devices in many industrial and IoT scenarios. To limit the overhead of certificate management for more constrained devices only the most crucial types of operations are specified as mandatory. To foster interoperability in more complex scenarios, other types of operations are specified as recommended or optional. "Header Protection for S/MIME", Bernie Hoeneisen, Daniel Gillmor, Alexey Melnikov, 2020-11-02, S/MIME version 3.1 has introduced a feasible standardized option to accomplish Header Protection. However, implementations of Header Protection can cause rendering issues on the receiving side. Clearer specifications regarding message processing, particularly with respect to header sections, are needed in order to resolve these rendering issues. 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. "CMP Algorithms", Hendrik Brockhaus, Hans Aschauer, Mike Ounsworth, Serge Mister, 2021-01-20, 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. "Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)", Russ Housley, 2020-12-30, This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithms with the Cryptographic Message Syntax (CMS) as specified in RFC 5652. "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", Russ Housley, 2020-12-21, This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2021-01-12, 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, 2015-04-02, 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 RFC6830, the protocol specification. "LISP YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino, 2020-09-08, 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, 2020-10-05, 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, 2020-08-24, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "LISP Virtual Private Networks (VPNs)", Victor Moreno, Dino Farinacci, 2020-08-03, This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. "LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc Portoles-Comeras, Vrushali Ashtaputre, Victor Moreno, Fabio Maino, Dino Farinacci, 2021-01-18, 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, 2020-11-02, 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, 2020-10-05, 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)", Alberto Rodriguez-Natal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino Farinacci, 2020-09-28, 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", Alberto Rodriguez-Natal, Vina Ermagan, Albert Cabellos-Aparicio, Sharon Barkai, Mohamed Boucadair, 2021-01-08, This document specifies an extension to the use of Map-Request to enable Publish/Subscribe (PubSub) operation for LISP. "Locator/ID Separation Protocol (LISP) Map-Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 2020-10-15, 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, 2020-09-13, 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, Sharon Barkai, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Dino Farinacci, 2020-10-17, This document specifies use of H3 and LISP to publish subscribe and reflect the real-time state and status of public spaces and public roads: - Tile by tile, indexed annotation of streets & curbs in near real time - Sharing hazards, blockages, parking, weather, maintenance, inventory.. - Between MobilityClients who produce and consume geo-state information - Using geo-spatial IP channels of current state of the physical world IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "LPWAN Static Context Header Compression (SCHC) for CoAP", Ana Minaburo, Laurent Toutain, Ricardo Andreasen, 2021-01-21, This draft defines how to compress the Constrained Application Protocol (CoAP) using the Static Context Header Compression (SCHC). SCHC is a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC for CoAP headers. The CoAP header structure differs from IPv6 and UDP since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP protocol messages format is asymmetric: the request messages have a header format different from the one in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. "Static Context Header Compression (SCHC) over LoRaWAN", Olivier Gimenez, Ivaylo Petrov, 2020-10-30, The Static Context Header Compression (SCHC) specification describes generic header compression and fragmentation techniques for Low Power Wide Area Networks (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies. This document specifies a profile of RFC8724 to use SCHC in LoRaWAN networks, and provides elements such as efficient parameterization and modes of operation. "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Laurent Toutain, 2020-11-02, 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-01-19, 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. 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. "Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF", Xiaohu Xu, Sriganesh Kini, Peter Psenak, Clarence Filsfils, Stephane Litkowski, Matthew Bocci, 2020-06-01, Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3 and BGP-LS. "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", Xiaohu Xu, Sriganesh Kini, Peter Psenak, Clarence Filsfils, Stephane Litkowski, Matthew Bocci, 2020-05-28, Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and BGP-LS. "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2021-01-11, This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. "YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2021-01-11, This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2020-10-22, 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, 2020-10-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 proposes new capability flag bits for PCE-CAP-FLAGS sub-TLV that can be announced as 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. "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Les Ginsberg, Huaimo Chen, Tony Przygienda, Dave Cooper, Luay Jalil, Srinath Dontula, Gyan Mishra, 2020-12-14, Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. "OSPF Prefix Originator Extensions", Aijun Wang, Acee Lindem, Jie Dong, Peter Psenak, Ketan Talaulikar, 2020-10-20, This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu, 2020-10-08, 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. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, 2020-10-31, 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 and OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510. "YANG Model for OSPFv3 Extended LSAs", Acee Lindem, Sharmila Palani, Yingzhen Qu, 2020-10-02, This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. "IS-IS Extended Hierarchy", Tony Li, Les Ginsberg, Paul Wells, 2021-01-03, 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 Strict-Mode for BFD", Ketan Talaulikar, Peter Psenak, Albert Fu, Rejesh Shetty, 2020-12-30, This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise this requirement of "strict- mode" of BFD session establishment for OSPF adjacency. If both OSPF neighbors advertise the "strict-mode" of BFD, adjacency formation will be blocked until a BFD session has been successfully established. "OSPF Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston, 2020-12-30, 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 signalling of this reverse metric, to be used on link(s) 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. "OSPFv3 Extensions for SRv6", Zhenbin Li, Zhibo Hu, Dean Cheng, Ketan Talaulikar, Peter Psenak, 2020-08-14, 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. This draft describes the OSPFv3 extensions required to support Segment Routing over an IPv6 data plane (SRv6). "Flooding Topology Minimum Degree Algorithm", Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2020-11-30, 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, 2020-11-18, Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that 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-01-18, This document describes an optional ISIS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection allows the creation of topologies where L1 areas provide transit forwarding for L2 destinations within an L2 topology. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. The L2 flood reflection adjacencies are used to flood L2 LSPDUs, and they are used in the L2 SPF computation. However, they are not used for forwarding. This arrangement gives the L2 topology better scaling properties. In addition, 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, Renwei Li, Yi Yang, Yanhe Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani, 2020-10-03, This document specifies a topology-transparent zone in an 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. "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", William Britto, Shraddha Hegde, Parag Kaneriya, Rejesh Shetty, Ron Bonica, Peter Psenak, 2020-11-15, 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. "Advertising L2 Bundle Member Link Attributes in OSPF", Ketan Talaulikar, Peter Psenak, 2020-10-29, 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. "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan, 2020-11-15, 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, 2020-12-23, 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-01-20, 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. Link State Vector Routing (lsvr) -------------------------------- "Shortest Path Routing Extensions for BGP Protocol", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2020-08-03, 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 a solution which leverages BGP Link-State distribution and the Shortest Path First (SPF) algorithm similar to Internal Gateway Protocols (IGPs) such as OSPF. "Usage and Applicability of Link State Vector Routing in Data Centers", Keyur Patel, Acee Lindem, Shawn Zandi, Gaurav Dawra, 2020-09-21, This document discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. "Layer 3 Discovery and Liveness", Randy Bush, Rob Austein, Keyur Patel, 2020-07-29, 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. 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. "TCP Usage Guidance in the Internet of Things (IoT)", Carles Gomez, Jon Crowcroft, Michael Scharf, 2020-10-30, This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. "Comparison of CoAP Security Protocols", John Mattsson, Francesca Palombini, Malisa Vucinic, 2020-11-02, This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN-GHC compression. DTLS is analyzed with and without Connection ID. "Alternative Elliptic Curve Representations", Rene Struik, 2020-12-17, 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, 2020-11-02, This document describes a minimal implementation of the 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, but instead to enable a limited implementation to interoperate with implementations of RFC 4303 ESP. This document describes what is required from RFC 4303 ESP as well as various ways to optimize compliance with RFC 4303 ESP. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP DiffServ Aware Credit Window Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2020-12-04, 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, 2020-12-04, This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are defined in an extensible and reusable fashion. Their use will be mandated in other documents defining specific DLEP extensions. "DLEP Traffic Classification Data Item", Bow-Nan Cheng, David Wiggins, Lou Berger, 2020-12-04, 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. It's use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP sub data items, and sub data items are defined to support DiffServ and Ethernet traffic classification. Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- "The CONNECT-UDP HTTP Method", David Schinazi, 2021-01-05, This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is similar to the HTTP CONNECT method, but it uses UDP instead of TCP. 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-connect-udp. 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-masque/draft-ietf-masque-connect-udp. "Requirements for a MASQUE Protocol to Proxy IP Traffic", Alex Chernyakhovsky, Dallas McCall, David Schinazi, 2021-01-08, 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. MBONE Deployment (mboned) ------------------------- "Multicast Considerations over IEEE 802 Wireless Media", Charles Perkins, Mike McBride, Dorothy Stanley, Warren Kumari, Juan Zuniga, 2020-10-26, Well-known issues with multicast have prevented the deployment of multicast in 802.11 (wifi) and other local-area wireless environments. This document describes the problems of known limitations with wireless (primarily 802.11) Layer-2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF, and by IEEE 802, for wireless media, as well as some operational choices that can be taken to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices. "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2020-10-29, This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. "Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, 2020-10-31, 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, 2020-10-31, 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, 2020-10-31, 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. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert, 2020-12-22, 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", Emad Omara, Benjamin Beurdouche, Eric Rescorla, Srinivas Inguva, Albert Kwon, Alan Duric, 2020-07-26, This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications, where the number of clients ranges from two to many. It is meant to protect against eavesdropping, tampering, and message forgery. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-architecture. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Using Multicast DNS to protect privacy when exposing ICE candidates", Youenn Fablet, Jeroen De Borst, Justin Uberti, Qingsi Wang, 2020-10-20, WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections. To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection. However, disclosure of these addresses has privacy implications. This document describes a way to share local IP addresses with other clients while preserving client privacy. This is achieved by concealing IP addresses with dynamically generated Multicast DNS (mDNS) names. Media OPerationS (mops) ----------------------- "Operational Considerations for Streaming Media", Jake Holland, Ali Begen, Spencer Dawkins, 2020-11-02, This document provides an overview of operational networking issues that pertain to quality of experience in delivery of video and other high-bitrate media over the internet. 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, 2020-08-04, 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. "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2020-08-12, This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2020-11-01, This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). "Refresh-interval Independent FRR Facility Protection", Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella, 2020-12-18, 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 LDP", Kamran 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, 2020-12-07, This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374. "Special Purpose Label terminology", Loa Andersson, Kireeti Kompella, Adrian Farrel, 2021-01-21, This document discusses and recommends a terminology that may be used when MPLS Special Purpose Labels (SPL) are specified and documented. This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator (7) when immediately preceded by the Extension Label (15). This document updates RFC 7274 and RFC 3032. "Updating the IANA MPLS LSP Ping Parameters", Loa Andersson, Mach Chen, Carlos Pignataro, Tarek Saad, 2020-11-25, This document updates RFC 8029 and RFC 8611 that both define IANA registries for MPLS LSP Ping. It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this name space with recent developments. "OSPFv3 CodePoint for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro, Mustapha Aissaoui, 2020-11-20, IANA has created "Protocol in the Segment IS Sub-TLV" registry and "Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the code point for different Interior Gateway Protocol (IGP). This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP protocol is OSPFv3. This document also clarifies that the existing codepoints of these two TLVs called "OSPF" shall only be used for OSPFv2. "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, 2020-11-19, 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, Daniel Voyer, Stefano Salsano, Mach Chen, 2021-01-06, 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 using probe messages. This document utilizes these mechanisms for Performance Delay and Loss Measurements in Segment Routing networks with MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end paths including SR-MPLS Policies. In addition, this document defines Return Path TLV for two-way performance measurement and Block Number TLV for loss measurement. "A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow, Siva Sivabalan, 2021-01-13, In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous 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 moght be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control prodocols. The existance 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 restricctions are to prevent overloading the control plane of the actioning router. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, 2020-08-20, This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. 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: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "RESTCONF Client and Server Models", Kent Watsen, 2020-08-20, 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: * "2020-08-20" --> 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, 2020-08-20, This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. 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: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "NETCONF Client and Server Models", Kent Watsen, 2020-08-20, 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: * "2020-08-20" --> 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, 2020-08-20, This document defines a YANG 1.1 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: * "2020-08-20" --> 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, 2020-08-20, 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, 2020-08-20, This document defines a YANG 1.1 data model for configuring globally- accessible bags of certificates and public keys that can be referenced by other data models for trust. 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: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael Scharf, 2020-08-20, This document defines three YANG 1.1 [RFC7950] modules to support the configuration of TCP clients and TCP servers, either as standalone or in conjunction with a stack protocol layer specific configurations. "An HTTPS-based Transport for Configured Subscriptions", Mahesh Jethanandani, Kent Watsen, 2020-11-16, This document defines a YANG data module for configuring HTTPS based configured subscription, as defined in RFC 8639. The use of HTTPS maximizes transport-level interoperability, while allowing for encoding selection from text, e.g. XML or JSON, to binary. "YANG Groupings for HTTP Clients and HTTP Servers", Kent Watsen, 2020-08-20, 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 * "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 this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> 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, 2020-11-16, 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, 2020-11-02, This documents 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, Paolo Lucente, 2020-11-02, This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared to already established notification mechanisms. Network Modeling (netmod) ------------------------- "A YANG Data Model for Syslog Configuration", Clyde Wildes, Kiran Koushik, 2018-03-16, This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. "Common Interface Extension YANG Data Models", Robert Wilton, David Ball, tapsingh@cisco.com, Selvakumar Sivaraj, 2020-07-29, This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Comparison of NMDA datastores", Alexander Clemm, Yingzhen Qu, Jeff Tantsura, Andy Bierman, 2020-09-25, This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. "YANG Module Versioning Requirements", Joe Clarke, 2021-01-05, 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. "A YANG Grouping for Geographic Locations", Christian Hopps, 2020-12-03, This document defines a generic geographical location object 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. "YANG Packages", Robert Wilton, Reshad Rahman, Joe Clarke, Jason Sterne, Bo Wu, 2020-11-02, This document defines YANG packages, a versioned organizational structure holding a set of related YANG modules that collectively define a YANG schema. It describes how packages: are represented on a server, can be defined in offline YANG instance data files, and can be used to define the schema associated with YANG instance data files. "YANG Schema Comparison", Robert Wilton, 2020-11-02, This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. This document defines a YANG extension that provides YANG annotations to help the tool accurately determine the scope of changes between two revisions. "YANG Versioning Solution Overview", Robert Wilton, 2020-11-02, This document gives an overview of the different documents that comprise a full solution to the YANG versioning requirements document. The purpose of this document is to help readers understand how the discrete parts of the YANG versioning solution fit together during working group development of the solution documents. "Self Describing Data Object Tags", Qin WU, Benoit Claise, Liang Geng, Zongpeng Du, Mohamed Boucadair, 2020-12-29, 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 characteristics data. It also can 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 state of all subscriptions of a particular Subscriber to be fetched is huge, the amount of data to be streamed out to the destination can be greatly 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. "A YANG Data model for ECA Policy Management", Qin WU, Igor Bryskin, Henk Birkholz, Xufeng Liu, Benoit Claise, 2021-01-18, This document defines a YANG data model for Event Condition Action (ECA) policy management. The ECA policy YANG module provides the ability to delegate some network management functions to the server which can take simple and instant action when a trigger condition on the system state is met. 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, 2020-08-10, 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, 2020-10-06, This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 2. Network Management (nmrg) ------------------------- "Intent-Based Networking - Concepts and Definitions", Alexander Clemm, Laurent Ciavaglia, Lisandro Granville, Jeff Tantsura, 2020-09-15, Intent and Intent-Based Networking (IBN) are taking the industry by storm. At the same time, those terms are used loosely and often 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 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 foundation to guide further definition of associated research and engineering problems and their solutions. "Intent Classification", Chen Li, Olga Havel, Will LIU, Adriana Olariu, Pedro Martinez-Julia, Jeferson Nobre, Diego Lopez, 2020-11-02, RFC7575 defines Intent as 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. Up to now, there is no commonly agreed definition, interface or model of intent. 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 facilitate solution development. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2020-12-18, 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[Qualifier] 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, 2020-09-09, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 2013-02-25, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, 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. "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, 2020-07-28, 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-01-06, 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-01-06, 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. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 2020-09-09, 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, 2020-09-09, 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-01-06, 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-01-06, 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, You Wang, Tao Lin, 2020-11-14, 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. "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, 2020-10-31, 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, 2020-11-02, 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. "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, 2020-12-11, This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. "Ruoska Encoding", Jukka-Pekka Makela, 2013-10-12, This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. "IS-IS Topology-Transparent Zone", Huaimo Chen, Renwei Li, Yi Yang, Yanhe Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani, 2020-08-18, This document presents a topology-transparent zone in an area. A zone is a 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. "ICANN Registry Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2021-01-04, 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 also described in this document. "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Phillip Hallam-Baker, 2021-01-13, 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, 2020-09-21, 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, 2020-12-10, 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. "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-01-12, 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, 2020-12-22, 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, 2020-09-09, This document collects some idea for a next generation of the Reliable Server Pooling framework. "Pronouncing and Using Chinese Personal Names", Hui Deng, Zhen Cao, 2020-09-17, This document gives general rules for how to pronounce Mandarin Chinese names in conversation, and how to determine which name is someone's surname. It also covers some other related topics about Chinese names. The intent is to allow IETF participants who are not familiar with Chinese to communicate better with Chinese participants. "Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen, Autumn Liu, Mehmet Toy, Vic liu, 2021-01-06, 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, 2020-11-26, This document proposes a generic routing method and protocol for a regular data center network, named as Fault-Avoidance Routing (FAR) protocol. FAR protocol provides a generic routing method for all types of regular topology network architectures that are proposed for large-scale cloud-based data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a concise manner. Fat-tree is taken as an example architecture to illustrate how FAR protocol can be applied in real operational scenarios. "SAML Profile for the Metadata Query Protocol", Ian Young, 2021-01-12, 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.15. "Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", Xian Zhang, Haomian Zheng, Oscar de Dios, Victor Lopez, Yunbin Xu, 2020-10-16, Resource sharing in a network means two or more Label Switched Paths (LSPs) use common pieces of resource along their paths. This can help save network resources and is useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is responsible for path computation with such requirement. Existing extensions to the Path Computation Element Protocol (PCEP) allow one path computation request for an LSP to be associated with other (existing) LSPs through the use of the PCEP Association Object. This document extends PCEP in order to support resource-sharing- based path computation as another use of the Association Object to enable better efficiency in the computation and in the resultant paths and network resource usage. "EAP-based Authentication Service for CoAP", Rafael Marin-Lopez, Dan Garcia-Carrillo, 2021-01-21, This document describes an authentication service that uses EAP transported by means of CoAP messages with the following purposes: o Authenticate a CoAP-enabled device that enters a new security domain against a AAA infrastructure through a domain Controller. o Bootstrap key material to protect CoAP messages exchanged between them. o Enable the establishment of Security Associations between them. "WebRTC Dependencies", Cullen Jennings, 2021-01-21, This draft will never be published as an RFC and is meant purely to help track the IETF dependencies from the W3C WebRTC documents. "Just because it's an ID doesn't mean anything... at all...", Warren Kumari, 2020-07-27, Anyone can publish an Internet Draft. This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "Mandatory Tags for DKIM Signatures", John Levine, 2020-08-30, The DKIM protocol applies a cryptographic signature to an e-mail message. This specification extends DKIM to allow new signature tags that validators are required to evaluate. The first such tag specifies a second signature that must be present for a signature to be valid. "PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Michael Richardson, 2020-09-28, 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. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/pcapng/pcapng.git "A JSON Encoding for HTTP Field Values", Julian Reschke, 2020-09-01, This document establishes a convention for use of JSON-encoded field values in HTTP fields. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, Reji Thomas, 2021-01-14, 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, 2020-09-09, 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. "Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen Cheng, Peng Wang, Tong Duan, 2020-09-21, 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, 2020-12-02, 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. "Extensions to OSPF for Advertising Prefix/Link Administrative Tags", Acee Lindem, Peter Psenak, 2020-09-23, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. 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 and links. 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. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2020-12-27, 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, 2020-12-28, 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, 2020-12-05, 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. "Encapsulating IP in UDP", Xiaohu Xu, Hamid Assarpour, Shaowen Ma, daniel.bernier@bell.ca, Darren Dukes, Shraddha Hegde, Yiu Lee, Fan Yongbing, 2020-12-22, Existing IP-in-IP encapsulation technologies are not adequate for efficient load balancing of IP-in-IP traffic across IP networks. This document specifies additional IP-in-IP encapsulation technology, referred to as IP-in-UDP (User Datagram Protocol), which can facilitate the load balancing of IP-in-IP traffic across IP networks. "TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor Dukhovni, Ash Wilson, 2020-10-30, 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. "Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Virtual Router Redundancy Protocol (VRRP) Use Case", Greg Mirsky, Jeff Tantsura, Gyan Mishra, 2020-11-01, This document discusses the use 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. "LISP support for Multi-Tuple EIDs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci, 2020-10-05, This document describes extensions for LISP to support EIDs based on tuples of multiple elements. "SMTP Service Extension for Client Identity", William Storey, 2020-12-07, 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. "Annotated Example SDP for WebRTC", Suhas Nandakumar, Cullen Jennings, 2020-12-17, The Web Real Time Communications (WebRTC) family of protocols defines mechanism for direct interactive rich communication using audio, video, and data between two peers' web browsers. With in the WebRTC framework, the Session Description Protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP offer/answer exchange mechanism This document provides an informational reference in describing the role of SDP and the offer/answer exchange mechanism for the most common WebRTC use cases. This document makes no changes to the SDP offer/answer exchange mechanism. "PCEP extensions for Distribution of Link-State and TE Information", Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra, 2020-11-24, 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. "MS-originated SMRs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Vina Ermagan, Fabio Maino, Sharon Barkai, 2020-10-05, 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. "Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan, Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2020-09-21, 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. "Problems in and among industries for the prompt realization of IoT and safety considerations", Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda, 2020-09-08, This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document. "PCEP Extensions for BIER-TE", Ran Chen, Zheng Zhang, Senthil Dhanaraj, Fengwei Qin, 2020-11-24, 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, 2020-12-14, 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, 2020-12-14, 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-01-10, 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, 2020-10-31, 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. "IPv6 Prefix Delegation and Multi-Addressing Models", Fred Templin, 2021-01-01, Requesting nodes typically acquire IPv6 prefixes from a prefix delegation service for the network. The requesting node can provision the prefix according to whether it acts as a router on behalf of any downstream networks and/or as a host on behalf of its local applications. In the latter case, the requesting node can use portions of the delegated prefix for its own multi-addressing purposes. This document therefore considers prefix delegation models for both the classic routing and various multi-addressing use cases. "Using compression in the Internet Key Exchange Protocol Version 2 (IKEv2)", Valery Smyslov, 2020-09-01, 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, 2020-10-19, 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, 2020-12-30, 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-01-13, 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. "Mathematical Mesh: Reference Implementation", Phillip Hallam-Baker, 2020-07-27, 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. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html. "Considerations for stateful vs stateless join router in ANIMA bootstrap", Michael Richardson, 2020-09-22, This document explores a number of issues affecting the decision to use a stateful or stateless forwarding mechanism by the join router (aka join assistant) during the bootstrap process for ANIMA. "Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira, 2020-12-14, 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, 2020-12-14, This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. "Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR)", Naoki Matsuhira, 2020-12-14, This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. "Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT)", Naoki Matsuhira, 2020-12-14, This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. "Multiple IPv4 - IPv6 address mapping translator (M46T)", Naoki Matsuhira, 2020-12-14, This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. "Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E)", Naoki Matsuhira, 2020-12-14, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Publishing Organization Boundaries in the DNS", John Levine, 2020-10-04, The organization that manages a subtree in the DNS is often different from the one that manages the tree above it. We describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models and can be queried with a small number of DNS lookups. "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2020-12-14, 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, 2020-11-01, 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, 2020-09-29, 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, 2020-09-22, 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. "Methodology for VNF Benchmarking Automation", Raphael Rosa, Christian Rothenberg, Manuel Peuster, Holger Karl, 2020-10-20, This document describes a common methodology for the automated benchmarking of Virtualized Network Functions (VNFs) executed on general-purpose hardware. Specific cases of automated benchmarking methodologies for particular VNFs can be derived from this document. An open source reference implementation is reported as running code embodiment of the proposed, automated benchmarking methodology. "Secure IoT Bootstrapping: A Survey", Mohit Sethi, Behcet Sarikaya, Dan Garcia-Carrillo, 2021-01-11, This draft provides an overview of the various terms that are used when discussing bootstrapping of IoT devices. We document terms that have been used within the IETF as well as other standards bodies. We investigate if the terms refer to the same phenomena or have subtle differences. We provide recommendations on the applicability of terms in different contexts. Finally, this document presents a survey of secure bootstrapping mechanisms available for smart objects that are part of an Internet of Things (IoT) network. The survey does not prescribe any one mechanism and rather presents IoT developers with different options to choose from, depending on their use-case, security requirements, and the user interface available on their IoT devices. "LISP Distinguished Name Encoding", Dino Farinacci, 2020-11-14, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2020-10-04, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2020-12-14, 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. "OpenPGP Web Key Directory", Werner Koch, 2020-11-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, 2020-09-21, 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. "OpenPGP Message Format", Werner Koch, brian carlson, Ronald Tse, Derek Atkins, Daniel Gillmor, 2020-08-31, { 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. "Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, 2021-01-06, 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-01-06, 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-01-06, 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. "Flow Classification in Information Centric Networking", Ilya Moiseenko, David Oran, 2021-01-13, For the ubiquitous and highly important Internet protocols (TCP, UDP, IP), flows are conventionally identified by the "5-tuple" of source and destination IP addresses, source and destination port, and protocol type in an IP packet. Information Centric Networking (ICN) is a new paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses. This document describes mechanisms allowing ICN forwarders, consumers, producers and other ICN nodes to encode, decode, and process equivalence class identifiers (flows) at any desired granularity of a routable name prefix and beyond the routable name prefix. This document is a product of the IRTF Information- Centric Networking Research Group (ICNRG). "PCEP Extension for Distribution of Link-State and TE information for Optical Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin-Yeong Yoon, 2020-09-08, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this Link State and TE information has been obtained from a link state routing protocol (supporting traffic engineering extensions). This document extends the Path Communication Element Communication Protocol (PCEP) with Link-State and TE information for optical networks. "Mathematical Mesh: Platform Configuration", Phillip Hallam-Baker, 2020-07-27, 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. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html. "The OpenConnect VPN Protocol Version 1.2", Nikos Mavrogiannopoulos, 2020-10-02, This document specifies version 1.2 of the OpenConnect Virtual Private Network (VPN) protocol, a secure VPN protocol that provides communications privacy over the Internet. That protocol is believed to be compatible with CISCO's AnyConnect VPN protocol. The protocol allows the establishment of VPN tunnels in a way that is designed to prevent eavesdropping, tampering, or message forgery. "Compact Format of IKEv2 Payloads", Valery Smyslov, 2020-09-23, 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, 2020-12-24, This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng, 2020-11-01, 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). The stateful PCE extension allows a redundancy scenario where a PCC can have redundant PCEP sessions towards multiple PCEs. In such a case, a PCC gives control of a LSP to only a single PCE, and only one PCE is responsible for path computation for this delegated LSP. 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. The inter-PCE stateful communication may also provide a faster update of the LSP states when such an event occurs. Finally, when, in a redundant PCE scenario, there is a need to compute a set of paths that are part of a group (so there is a dependency between the paths), there may be some cases where the computation of all paths in the group is not handled by the same PCE: this situation is called a split-brain. This split-brain scenario may lead to computation loops between PCEs or suboptimal path computation. 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 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, 2020-11-18, 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, 2020-11-15, 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, 2020-12-22, 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. "Report on Problem Solving Experiment for Realization of Web-API-based IoT", Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda, Shintaro Ogura, Koichi KUNITAKE, 2020-09-09, The University of Tokyo (UOT) is currently performing a demonstration experiment in COMMA House, the experimental smart-house owned by UOT and used as a connected house. The things installed in the house (Things) are operated using applications on smartphones and other devices. The various Things in the smart-house are operated online via a Web API that has been created as a prototype. This report is an overview of the experimental demonstration, which is gradually clarifying that Web API should be effective for solving issues for IoT. "Service Function Chaining Use Cases in Fog RAN", Carlos Bernardos, Akbar Rahman, Alain Mourad, 2020-09-17, Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols. "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff Tantsura, 2020-11-15, 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, 2020-12-04, 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. "Internet Protocol version 10 (IPv10) Specification", Khaled Omar, 2020-10-21, This document specifies version 10 of the Internet Protocol (IPv10), a solution that allows IPv4-only hosts to communicate with IPv6-only hosts and vice versa. "Mobility Capability Negotiation and Protocol Selection", Zhiwei Yan, Guanggang Geng, Jong-Hyouk Lee, Tao Huang, 2020-09-20, Based on different requirements, multiple mobility management protocols have been developed. Different protocols have different functional requirements on the network element or the host and then a scheme should be used in order to support the negotiation and selection of adopted mobility management protocol when a host accesses to a new network. In this draft, this issue is analyzed. "Network Service Header (NSH) Context Header Allocation: Timestamp", Tal Mizrahi, Ilan Yerushalmi, David Melman, Rory Browne, 2020-10-21, This memo defines an allocation for the Context Headers of the Network Service Header (NSH), which incorporates the packet's timestamp, a sequence number, and a source interface identifier. "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue, Richard Bradbury, Sam Hurst, 2020-08-07, 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. "RFC Style Guide", John Levine, RFC Editor, 2020-10-04, This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide". "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, Zhong Xiang, Sandra Cespedes, 2020-11-02, 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, 2020-11-02, 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, 2020-09-22, 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-01-06, 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-01-06, 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, 2020-12-07, 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. "Deployments With Insertion of IPv6 Segment Routing Headers", Daniel Voyer, Clarence Filsfils, Darren Dukes, Satoru Matsushima, John Leddy, Zhenbin Li, Jim Guichard, 2020-11-20, SRv6 is deployed in multiple provider networks. This document describes the usage of SRH insertion and deletion within the SR domain and how security and end-to-end integrity is guaranteed. "NEAT Sockets API", Thomas Dreibholz, 2020-07-28, 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, 2020-11-15, 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-01-10, 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, 2020-11-02, This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) using active tails with unsolicited notifications mode. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session in this environment. "KHALED Routing Protocol (KRP) Specification", Khaled Omar, 2020-10-21, This document specifies KHALED Routing Protocol (KRP), an Exterior Gateway Protocol (EGP) that introduces a new way of routing IP packets from the source to the destination through different Autonomous Systems (ASs). The enhancements that KRP adds are: a) Decreasing the BGP routing table (using the regions concept). b) Enhancing the routing function (using the stored information). c) Choosing a better path (using the AS Weight) c) Enhancing the QoS (using the information separation). KRP sometimes referred to as Regional Routing Protocol (RRP). "Regional Routing Protocol (RRP) Specification", Khaled Omar, 2020-10-21, This document specifies Regional Routing Protocol, sometimes referred to as KHALED Routing Protocol (KRP). "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak, 2020-12-25, 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, 2020-11-29, 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]. "Numbering Exchange Protocol (NEP) Specification", Khaled Omar, Luis Camara, 2020-10-21, This document specifies the Numbering Exchange Protocol (NEP), an Interior Gateway Protocol (IGP) that combines three metrics: delay, bandwidth and number of hops. "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing", Daniel King, John Drake, Haomian Zheng, 2020-10-02, Network abstraction is a technique that can be applied to a network domain that utilizes a set of policies to select network resources and obtain a view of potential connectivity across the network. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineering (TE) network that utilizes IETF technology. It also identifies the features of network slicing not currently within the scope of ACTN, and indicates where ACTN might be extended. "Satellite Internet (SI) Specification", Khaled Omar, 2020-10-21, This document specifies Satellite Internet (SI). "BFD in Demand Mode over Point-to-Point MPLS LSP", Greg Mirsky, 2020-09-09, This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. "BGP signalled private MPLS-labels", Kaliraj Vairavakkalai, Jeyananth Jeganathan, 2020-08-18, 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. "pretty Easy privacy (pEp): Privacy by Default", Volker Birk, Hernani Marques, Bernie Hoeneisen, 2020-11-02, The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely- deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. "SFC OAM for path consistency", Greg Mirsky, Ting Ao, Zhonghua Chen, Kent Leung, Gyan Mishra, 2021-01-19, Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected due to classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all SFC elements are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred to in this document as the path consistency of the SFC. This document defines a new SFC active OAM method to support SFC consistency check, i.e., verification that all elements of the given SFC are being traversed in the expected order. "Controlled Return Path for Service Function Chain (SFC) OAM", Greg Mirsky, Ting Ao, Zhonghua Chen, Gyan Mishra, 2021-01-19, This document defines an extension to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enables control of the Echo Reply return path directing it over a Reverse Service Function Path. Enforcing the specific return path can be used to verify the bidirectional connectivity of SFC and increase the robustness of SFC OAM. "SOCKS Protocol Version 6", Vladimir Olteanu, Dragos Niculescu, 2020-11-02, The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication. "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu, 2020-12-13, 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. "Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses", Roland Jesske, 2020-11-24, 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. "Problem Statement and Considerations for ROAs issued with Multiple Prefixes", Zhiwei Yan, Randy Bush, Guanggang Geng, Jiankang Yao, 2020-09-20, The address space holder needs to issue an ROA object when it authorizes one or more ASes to originate routes to multiple prefixes. During the process of ROA issuance, the address space holder needs to specify an origin AS for a list of IP prefixes. Besides, the address space holder has a free choice to put multiple prefixes into a single ROA or issue separate ROAs for each prefix based on the current specification. This memo analyzes and presents some operational problems which may be caused by the misconfigurations of ROAs containing multiple IP prefixes. Some suggestions and considerations also have been proposed. "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri, 2020-09-08, 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. "Guide for building an ECC pki", Robert Moskowitz, Henk Birkholz, Liang Xia, Michael Richardson, 2020-08-09, This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. "Signed HTTP Exchanges", Jeffrey Yasskin, 2020-07-27, This document specifies how a server can send an HTTP exchange--a request URL, content negotiation information, and a response--with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks. "IPv6 Source Routing for ultralow Latency", Andreas Foglar, Mike Parker, Theodoros Rokkas, 2020-07-27, This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency. "MISP object template format", Alexandre Dulaunoy, Andras Iklody, 2021-01-05, This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format. "Simple Group Keying Protocol (SGKP)", Donald Eastlake, Dacheng Zhang, 2021-01-10, 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. "Internet Protocol Mixture (IPmix) Specification", Khaled Omar, 2020-10-21, This document specifies the Internet Protocol Mixture (IPmix). a solution that allows IPv4-only hosts to communicate with IPv6-only hosts and vice versa. "Elliptic curve 2y^2=x^3+x over field size 8^91+5", Daniel Brown, 2020-10-02, 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. "Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP", Greg Mirsky, Yanhua Zhao, Gyan Mishra, 2020-12-08, This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path. "A YANG Data Model for Ethernet TE Topology", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2020-12-04, 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 Client-layer Tunnel", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2020-08-17, 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. "Supporting BIER in IPv6 Networks (BIERin6)", Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra, 2020-12-10, 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. "Echo Request/Reply for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, Lei Bo, 2021-01-20, This document describes an extension to the echo request/reply mechanisms used in IPv6, MPLS and SFC 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. "I2NSF on the NFV Reference Architecture", Hyunsik Yang, Younghan Kim, Jaehoon Jeong, 2020-11-02, This document describes the integration of Interface to Network Security Functions (I2NSF) Framework into the Network Functions Virtualization (NFV) Reference Model. This document explains how the components and interfaces in the I2NSF Framework can be placed in the NFV reference architecture, and also explains the procedures of the lifecycle management of Network Security Functions (NSFs) according to a user's security policy specification in the I2NSF framework on the NFV system. "YANG Model for QoS Operational Parameters", Aseem Choudhary, Ing-Wher Chen, 2020-10-22, This document describes a YANG model for Quality of Service (QoS) operational parameters. "Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network", Yun Chung, Min Kang, Younghan Kim, 2020-10-28, This document proposes extension of probabilistic routing protocol using history of encounters and transitivity (PRoPHET) for information centric network. "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. "A Unified Stateful/Stateless Configuration Service for IPv6", Fred Templin, 2021-01-01, IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for nodes to discover neighbors, routers, prefixes and other services on the link. It also supports a manner of StateLess Address AutoConfiguration (SLAAC), while the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specifies a separate stateful service. This document presents IPv6ND extensions for providing a unified stateful/stateless configuration service. "Ground-Based LISP for the Aeronautical Telecommunications Network", Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy, 2020-07-25, This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures. "HTTP Live Streaming 2nd Edition", Roger Pantos, 2020-10-29, This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 10 of this protocol. "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin Cantrell, 2020-09-13, 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, 2020-11-18, This document proposes a service health check response format for HTTP APIs. "Device Enrollment in IETF protocols -- A Roadmap", Michael Richardson, 2020-10-07, This document provides an overview of enrollment or imprinting mechanisms in current IETF protocols. This document is being worked on in the ANIMA-WG, and on github at: https://github.com/anima-wg/enrollment-roadmap "impl-info: A link relation type for disclosing implementation information", Carsten Bormann, 2020-09-27, For debugging, it is often helpful to have information about the implementation of a peer. The present specification defines a link relation type, "impl-info", that can be used to convey such information via self-description, such as in the "/.well-known/core" resource. "Simple Group Keying Protocol TRILL Use Protfiles", Donald Eastlake, Dacheng Zhang, 2021-01-10, 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). "IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2020-07-26, 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. "Information-centric Routing for Opportunistic Wireless Networks", Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Carlos Borrego, 2020-09-16, This draft describes the Data reAchaBility BasEd Routing (DABBER) protocol. DABBER aims to provide a name-based routing solution to support the operation of Information-centric Networking frameworks in opportunistic wireless networks. By "opportunistic wireless networks" it is meant multi-hop wireless networks where finding an end-to-end path between any pair of nodes at any moment in time may be a challenge. The goal is to assist in better defining opportunities for the transmission of Interest packets in a store- carry-and-forward manner, based on a proactive approach. The document describes how to integrate DABBER in a networking node that implements some ICN approach, such as Named-Data Networking (NDN) or Content Centric Networking (CCN), along with the specification of the proactive approach based on the dissemination of name-prefix information. "Unified Identifier in IPv6 Segment Routing Networks", Weiqiang Cheng, Greg Mirsky, Shaofu Peng, Liu Aihua, Gyan Mishra, 2021-01-05, 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 MPLS data plane by encoding segments in the MPLS label stack. It also can be applied to 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, 2020-12-04, Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. "Synchronizing Internet Clock frequency protocol (sic)", Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib, 2020-10-27, Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware. "Extension for Stateful PCE to allow Optional Processing of PCEP Objects", Cheng Li, Haomian Zheng, Stephane Litkowski, 2020-11-01, 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. "Hierarchy of IP Controllers (HIC)", Zhenbin Li, Dhruv Dhody, Huaimo Chen, 2020-11-02, 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). "Multilinear Galois Mode (MGM)", Stanislav Smyshlyaev, Vladislav Nozdrunov, Vasily Shishkin, Ekaterina Griboedova, 2020-07-29, Multilinear Galois Mode (MGM) is an authenticated encryption with associated data (AEAD) block cipher mode based on EtM principle. MGM is defined for use with 64-bit and 128-bit block ciphers. MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g. TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher. "Using Identity as Raw Public Key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", HAIGUANG Wang, Yanjiang Yang, Xin Kang, Zhaohui Cheng, chenmeiling, 2020-10-09, This document specifies the use of identity as a raw public key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The TLS protocol procedures are kept unchanged, but signature algorithms are extended to support Identity-based signature (IBS). A few Identity-based signature algorithms from different standard organizations are supported in the current version. "Blockchain Transaction Protocol for Constraint Nodes", Pascal Urien, 2020-12-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, 2020-08-03, 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 Link-State Extensions for BGP-only Fabric", Ketan Talaulikar, Clarence Filsfils, krishnaswamy ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani, 2020-09-08, 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. "Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN", Jie Dong, Stewart Bryant, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, Francois Clad, 2021-01-18, Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based virtual underlay networks, which has customized network topology and resource attributes required by one or a group of customers and/or services. Such virtual networks are the SR instantiations of Virtual Transport Networks (VTNs). This document describes a suggested use of resource-aware SIDs to build SR based VTNs. "Geneve encapsulation for In-situ OAM Data", Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Nagendra Nainar, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey Spiegel, 2020-11-19, 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 proposes a new Geneve tunnel option and outlines how IOAM data fields are carried in the option data field. "BGP Extended Community for Identifying the Target Nodes", Jie Dong, Shunwan Zhuang, Gunter Van de Velde, 2020-11-02, 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-01-06, 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, 2020-11-16, Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments. "Multipath Extensions for QUIC (MP-QUIC)", Quentin De Coninck, Olivier Bonaventure, 2020-11-02, 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, Kamran Raza, Mankamana Mishra, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko, 2020-11-26, Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP in a network that supports MTR and/or FA, mLDP is required to become topology and FA aware. This document specifies extensions to mLDP to support MTR with FA such that when building a Multi-Point LSPs it can follow a particular topology and algorithm. "Service Function discovery in fog environments", Carlos Bernardos, Alain Mourad, 2020-09-17, 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-01-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, 2020-11-24, 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, 2020-11-02, 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, 2020-11-02, 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 spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. "OAuth 2.0 Assisted Token", Jacob Ideskog, Travis Spencer, 2021-01-05, This document extends the OAuth 2.0 framework to include an additional authorization flow for single page applications called the assisted token flow. It enables OAuth clients written in scripting languages, like JavaScript, to request user authorization using a simplified method compared to other flows. Communication does not rely on redirection of the user agent, but instead leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint. "In-situ OAM raw data export with IPFIX", Mickey Spiegel, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, 2020-11-02, 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-01-04, 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, 2020-11-16, 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. "OSPF Flooding Reduction in Massively Scalable Data Centers (MSDCs)", Xiaohu Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma, 2020-12-22, OSPF is one of the used underlay routing protocol for MSDC (Massively Scalable Data Center) networks. For a given OSPF router within the CLOS topology, it would receive multiple copies of exactly the same LSA from multiple OSPF neighbors. In addition, two OSPF neighbors may send each other the same LSA simultaneously. The unnecessary link-state information flooding wastes the precious process resource of OSPF routers greatly due to the presence of too many OSPF neighbors for each OSPF router within the CLOS topology. This document proposes extensions to OSPF so as to reduce the OSPF flooding within such MSDC networks. The reduction of the OSPF flooding is much beneficial to improve the scalability of MSDC networks. These modifications are applicable to both OSPFv2 and OSPFv3. "IS-IS Flooding Reduction in MSDC", Xiaohu Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma, 2020-12-22, IS-IS is commonly used as an underlay routing protocol for MSDC (Massively Scalable Data Center) networks. For a given IS-IS router within the CLOS topology, it would receive multiple copies of exactly the same LSP from multiple IS-IS neighbors. In addition, two IS-IS neighbors may send each other the same LSP simultaneously. The unnecessary link-state information flooding wastes the precious process resource of IS-IS routers greatly due to the fact that there are too many IS-IS neighbors for each IS-IS router within the CLOS topology. This document proposes some extensions to IS-IS so as to reduce the IS-IS flooding within MSDC networks greatly. The reduction of the IS-IS flooding is much beneficial to improve the scalability of MSDC networks. "IS-IS Multi Topology Deployment Considerations", Uma Chunduri, Jeff Tantsura, Shraddha Hegde, 2020-11-24, This document analyzes IS-IS Multi Topology (MT) applicability in various IS-IS deployments. This document explores the nuances around the terminology and usage of various IS-IS address families, topologies with different considerations, for choosing the right combination for a specific deployment scenario. This document also discusses various ways one can deploy IPv6 only IS-IS topology. "DLEP IEEE 802.1Q Aware Credit Window Extension", David Wiggins, Lou Berger, 2020-12-04, 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. "SR Policy Implementation and Deployment Considerations", Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes, 2020-10-12, 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. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture. "RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks", Shanguo Huang, Shan Yin, Shuang Zhou, 2020-11-15, 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, 2020-11-23, 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. "General Security Considerations for Cryptoassets Custodians", Masashi Sato, Masaki Shimaoka, Hirotaka Nakajima, 2020-12-16, This document discusses the technical and operational risks of cryptoassets custodians and its security controls to avoid the unintended transactions for its customers. 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/cgtf/draft-crypto-assets-security-considerations. "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen, 2020-11-17, This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms. "The IPv6 Tunnel Payload Forwarding (TPF) Option", Ron Bonica, Yuji Kamite, Luay Jalil, Yifeng Zhou, Gang Chen, 2020-08-30, This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. "Web Bundles", Jeffrey Yasskin, 2020-07-27, Web bundles provide a way to bundle up groups of HTTP responses, with the URLs and request URLs that produced them, to transmit or store them together. They can include multiple top-level resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and efficiently store 8-bit resources. "DNS Web Service Discovery", Phillip Hallam-Baker, 2021-01-13, 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. "BGP FlowSpec Payload Matching", Anurag Khare, Philippe BERGEON, John Scudder, Luay Jalil, Michael Gallagher, Kirill Kasavchenko, 2020-09-01, The rise in frequency, volume, and pernicious effects of DDoS attacks has elevated them from fare for the specialist to generalist press. Numerous reports detail the taxonomy of DDoS attacks, the varying motivations of their attackers, as well as the resulting impact for their targets ranging from internet or business services to network infrastrutures. BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") can be used to rapidly disseminate filtering rules to mitigate (distributed) denial-of-service (DoS) attacks. Operators can use existing FlowSpec components to match typical n-tuple criteria in pre-defined packet header fields such as IP protocol, IP prefix or port number. Recent enhancements to IP Router forwarding plane filter implementations also allow matches at arbitrary locations within the packet header or payload. This capability can be used to essentially match a signature for the attack traffic and can be combined with traditional n-tuple filter criteria to mitigate volumetric DDoS attacks and reduce false positive to a minimum. To support this new filtering capability we define a new FlowSpec component, "Flexible Match Conditions", with similar matching semantics to those of existing components. This component will allow the operator to define a new match condition using a combination of offset and pattern values. "Preferred Path Routing (PPR) in IS-IS", Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu, 2020-09-28, This document specifies Preferred Path Routing (PPR), an extensible method of providing path based dynamic routing for a number of packet types including IPv4, IPv6 and MPLS. PPR uses a simple encapsulation to add the path identity to the packet. PPR can also be used to mitigate the MTU and data plane processing issues that may result from Segment Routing (SR) packet overhead; and also supports further extensions along the paths. "PCE Controlled ID Space", Cheng Li, Mach Chen, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2020-10-30, 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. "TLS 1.3 Authentication and Integrity only Cipher Suites", Nancy Cam-Winget, Jack Visoky, 2020-10-21, There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though message integrity for all communications and mutual authentication during tunnel establishment are both still mandated. Examples of such use cases are given, although a threat model is necessary to determine whether or not a given situation falls into this catergory of use cases. In order to serve these use cases, this document defines the use of HMAC only cipher suites for TLS 1.3, which provides mutual authentication and data authenticity, but not data confidentiality. 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. "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark, 2020-11-29, This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. "Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT", Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki Ishida, 2020-09-09, This paper describes issues for solutions through cloud inter- connection to structural problems, which are called as "silo effects" found in cloud-connected electric home appliances, housing equipment and sensors in the face of increasingly accelerated connection of them. Specifically, this paper explains an inter-connection agreement considered to be required for enhancement of cloud inter- connection, what performance guarantee as well as IoT supervising and management should be, necessity of inter-connection HUB which is able to provide inter-connection amongst the preponderance of private cloud groups, and the necessity of a mechanism to avoid threats that cause danger to users when we make the inter-connection. "Security Policy Translation in Interface to Network Security Functions", Jaehoon Jeong, Jinhyuk Yang, Chaehong Chung, Jinyong Kim, 2020-11-02, 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, 2020-09-09, 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, 2020-11-01, 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", J. Zhang, Y. Yang, 2021-01-14, 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. "Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane", Chandrasekar R, Vishnu Beeram, Harish Sitaraman, 2021-01-03, Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). These tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures. "LISP Control Plane for SRv6 Endpoint Mobility", Alberto Rodriguez-Natal, Vina Ermagan, Fabio Maino, Darren Dukes, Pablo Camarillo, Clarence Filsfils, 2020-07-26, This document describes the use of the LISP Control Plane to support endpoint mobility and Location/ID separation in Segment Routing v6 (SRv6) deployments. "Building blocks for Slicing in Segment Routing Network", Zafar Ali, Clarence Filsfils, Pablo Camarillo, Daniel Voyer, 2020-11-16, This document describes how to build network slice using the Segment Routing based technology. It explains how the existing building blocks specified for the Segment Routing can be used for this purpose. "Terminology for Cryptoassets", Hirotaka Nakajima, Masanori Kusunoki, Keiichi Hida, Yuji Suga, Tatsuya Hayashi, 2020-12-31, This document provides terminology used in cryptoassets. "Flexible Session Protocol", Jun-an Gao, 2020-10-19, 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 Ubiquitous authenticated encryption o 0-RTT multiplication of connections o On-the-wire compression "Transport Network aware Mobility for 5G", Uma Chunduri, Renwei Li, Sridhar Bhaskaran, John Kaippallimalil, Jeff Tantsura, Luis Contreras, Praveen Muley, 2020-11-02, This document specifies a framework and mapping from slices in 5G mobile systems to transport slices in IP and Layer 2 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 should be mapped to the transport network slice characteristics that include bandwidth, latency and criteria such as isolation, directionality and disjoint routes. Mobile slice criteria need to be 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 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 is also discussed. This is based on mapping between mobile and transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4). "BGP-LS Advertisement of Segment Routing Service Segments", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Francois Clad, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Jim Guichard, Cheng Li, 2020-08-14, 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. "Implementation notes for RFC7991,", Henrik Levkowetz, 2020-12-15, 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, 2020-09-04, Security events communicated within Security Event Tokens may support a variety of identifiers to identify the subject and/or other principals related to the event. This specification formalizes the notion of subject identifiers as named sets of well-defined claims describing the subject, a mechanism for representing subject identifiers within a JSON object such as a JSON Web Token (JWT) or Security Event Token (SET), and a registry for defining and allocating names for these claim sets. "YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng, Qiufang Ma, 2021-01-22, 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, 2020-09-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, 2020-08-18, 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, 2020-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, 2020-09-01, 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. "Asymmetric Extended Route Optimization (AERO)", Fred Templin, 2021-01-01, This document specifies the operation of IP over Overlay Multilink Network (OMNI) interfaces using the Asymmetric Extended Route Optimization (AERO) internetworking and mobility management service. AERO/OMNI use an IPv6 link-local address format that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links ND to IP forwarding. Prefix delegation/registration services are employed for network admission and to manage the routing system. Multilink operation, mobility management, quality of service (QoS) signaling and route optimization are naturally supported through dynamic neighbor cache updates. Standard IP multicasting services are also supported. AERO is a widely-applicable mobile internetworking service especially well-suited to aviation services, intelligent transportation systems, mobile Virtual Private Networks (VPNs) and many other applications. "Guide for building an EDDSA pki", Robert Moskowitz, Henk Birkholz, Michael Richardson, 2020-09-04, This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. Certificates in this guide can be either ED25519 or ED448 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse, Jordi Martinez, Lee Howard, Richard Patterson, Ian Farrer, 2021-01-09, 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 five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. "Benchmarking Methodology for EVPN VPWS", sudhin jacob, Kishore Tiruveedhula, 2020-10-26, This document defines methodologies for benchmarking EVPN-VPWS performance. EVPN-VPWS is defined in RFC 8214, and is being deployed in Service Provider networks. Specifically this document defines the methodologies for benchmarking EVPN-VPWS Scale convergence, Fail over,Core isolation,high availability and longevity. "Discovery of OSCORE Groups with the CoRE Resource Directory", Marco Tiloca, Christian Amsuess, Peter van der Stok, 2020-11-02, 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. "Postcard-based On-Path Flow Data Telemetry using Packet Marking", Haoyu Song, Tianran Zhou, Zhenbin Li, Greg Mirsky, Jongyoon Shin, Kyungtae Lee, 2020-10-30, The document describes a packet-marking variation of the Postcard- Based Telemetry (PBT), referred to as PBT-M. Unlike the instruction- based PBT, as embodied in [I-D.ietf-ippm-ioam-direct-export], PBT-M does not require the encapsulation of a telemetry instruction header, so it avoids some of the implementation challenges of the instruction-based PBT. However, PBT-M has unique issues that need to be considered. This document serves as a scheme overview and provides design guidelines applicable to implementations in different network protocols. "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola, Shinyoung Lee, Mauro Cociglio, Weidong Li, 2021-01-18, This document extends the IPv6 alternate marking option to provide the enhanced capabilities. "Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs", Mallory Knodel, Niels ten Oever, 2020-08-25, 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. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2020-11-01, The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. 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 protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers for Segment Routing (SR) in IPv6 (SRv6), in addition to computing the SRv6 paths for packet flows and telling the edge routers what instructions to attach to packets as they enter the network. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2020-11-01, The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. 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). PCE was developed to derive paths for MPLS P2MP LSPs, which are supplied to the head end (root) of the LSP using PCEP. PCEP has been proposed as a control protocol to allow the PCE to be fully enabled as a central controller. 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 PCEP extensions for using the PCE as the central controller for P2MP TE LSP. "BMP for BGP Route Leak Detection", Yunan Gu, China Telecom, Di Ma, Shunwan Zhuang, 2020-09-10, According to RFC7908 [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, 2020-07-27, 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 Protection", Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu, 2020-10-23, 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 fast re-route protection against the failure of a SR-TE path after the IGP converges. It provides fast re-route protection for an adjacency segment, a node segment and a binding segment of the path. "Edge Data Discovery for COIN", Mike McBride, Dirk Kutscher, Eve Schooler, Carlos Bernardos, Diego Lopez, Xavier de Foy, 2020-11-01, This document describes the problem of distributed data discovery in edge computing, and in particular for computing-in-the-network (COIN), which may require both the marshalling of data at the outset of a computation and the persistence of the resultant data after the computation. Although the data might originate at the network edge, as more and more distributed data is created, processed, and stored, it becomes increasingly dispersed throughout the network. There needs to be a standard way to find it. New and existing protocols will need to be developed to support distributed data discovery at the network edge and beyond. "AC-Aware Bundling Service Interface in EVPN", Ali Sajassi, Mankamana Mishra, Samir Thoria, Patrice Brissette, Jorge Rabadan, John Drake, 2020-08-18, 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 bridge domain. [RFC7432] defines three different type of service interface which serve different requirements but none of them address the requirement to be able to support multiple subnets within single bridge domain. In this draft we define new service interface type to support multiple subnets in single bridge 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-01-06, 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, 2020-10-05, As networks increase in scale and network operations become 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. Emerging on-path telemetry techniques which provide high-precision flow insight and real-time issue notification are required to ensure suitable quality of experience for users and applications, and identify faults or network deficiencies before they become critical. This document outlines a high-level framework to provide an operational environment that utilizes existing and emerging on-path telemetry techniques to enable the collection and correlation of performance 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 use the referenced techniques as well as to motivate further work to enhance the ecosystem . "YANG Data Model for OSPF SRv6", Zhibo Hu, Xuesong Geng, Kamran Raza, Yingzhen Qu, Acee Lindem, 2020-10-08, This document defines a YANG data model that can be used to configure and manage OSPFv3 SRv6 [I-D.ietf-lsr-ospfv3-srv6-extensions]. "Preferred Path Route Graph Structure", Uma Chunduri, Toerless Eckert, 2020-09-28, This document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes. "SRv6 and MPLS interworking", Swadesh Agrawal, Zafar Ali, Clarence Filsfils, Daniel Voyer, Zhenbin Li, 2020-08-14, This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. "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, 2020-11-15, 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. "Private Discovery", Bob Bradley, 2020-12-28, This document specifies a protocol for advertising and discovering devices and services while preserving privacy and confidentiality. "Benchmarks and Methods for Multihomed EVPN", Alfred Morton, Jim Uttaro, 2020-11-02, Fundamental Benchmarking Methodologies for Network Interconnect Devices of interest to the IETF are defined in RFC 2544. Key benchmarks applicable to restoration and multi-homed sites are in RFC 6894. This memo applies these methods to Multihomed nodes implemented on Ethernet Virtual Private Networks (EVPN). "RPKI Route Origin Validation State Unverified", Oliver Borchert, Doug Montgomery, 2021-01-15, In case operators decide not to evaluate BGP route prefixes according to RPKI route origin validation (ROV), none of the available states as specified in RFC 6811 do properly represent this decision. This document introduces "Unverified" as well-defined validation state which allows to properly identify route prefixes as not evaluated according to RPKI route origin validation. "BGPsec Validation State Unverified", Oliver Borchert, Doug Montgomery, 2021-01-15, In case operators decide to delay BGPsec path validation, none of the available states do properly represent this decision. This document introduces "Unverified" as a well-defined validation state which allows to properly identify a non-evaluated BGPsec routes as not verified. "The Standards on a Cloud Service Framework and Protocol for Construction, Migration, Deployment,and Publishing of Internet-Oriented Scalable Web Software Systems in Non-Programming Mode", Can Yang, Linghui Du, Haibo Sun, Kemin Qu, Guoqiang Han, 2020-11-21, This draft mainly focuses on the scalable architecture and publishing protocol standard of REST-based SAAS cloud model Web software in non- programming mode, stipulates the data structure pattern and data exchange protocol for the construction and release of REST-based scalable Web cloud service software systems. Using the standardized framework and protocol, users can easily and quickly design their own software systems in the cloud, transfer and release data, which may make conventional software development so ease to improve the efficiency of complex database construction and server management. Without having to write codes under the standard framework, users can get consistent style background to create service, rapidly develop web application systems with the function of standard data management and data maintenance, and directly publish the software system to the end users of the Internet for access and use. And provide RESTful APIs to facilitate external access to required service resources. The framework can thus greatly shorten the software development life cycle, and save a great deal of development cost and maintenance overhead. "Uberlay Interconnection of Multiple LISP overlays", Victor Moreno, Dino Farinacci, Alberto Rodriguez-Natal, Marc Portoles-Comeras, Fabio Maino, Sanjay Hooda, 2020-08-03, 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. "Multiple Layer Resource Optimization for Optical as a Service", Hui Yang, Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang, 2020-10-26, 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, 2020-12-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. "MessageVortex Protocol", Martin Gwerder, 2020-09-12, The MessageVortex (referred to as Vortex) protocol achieves different degrees of anonymity, including sender, receiver, and third-party anonymity, by specifying messages embedded within 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, 2020-11-02, 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. "A Light Weight IOAM for SRv6 Network Programming", Cheng Li, Weiqiang Cheng, Mach Chen, Stefano Previdi, Zhenqiang Li, 2020-08-03, In-situ OAM(IOAM) records OAM information within the packet while the packet traverses a particular network domain. This document defines a light weight IOAM method for SRv6 network programming. In this method, IOAM information is carried in the data packet by the SIDs in the SRH. "The Multibase Data Format", Juan Benet, Manu Sporny, 2020-08-18, 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, 2020-10-31, 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. "CoRE Resource Directory Extensions", Christian Amsuess, 2020-11-02, A collection of extensions to the Resource Directory [I-D.ietf-core-resource-directory] that can stand on their own, and have no clear future in specification yet. "Mathematical Mesh 3.0 Part IX: The Trust Mesh", Phillip Hallam-Baker, 2021-01-13, 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. "OAM for LPWAN using Static Context Header Compression (SCHC)", Dominique Barthel, Laurent Toutain, Arunprabhu Kandasamy, Diego Dujovne, Juan Zuniga, 2020-11-02, With IP protocols now generalizing to constrained networks, users expect to be able to Operate, Administer and Maintain them with the familiar tools and protocols they already use on less constrained networks. OAM uses specific messages sent into the data plane to measure some parameters of a network. Most of the time, no explicit values are sent is these messages. Network parameters are obtained from the analysis of these specific messages. This can be used: * To detect if a host is up or down. * To measure the RTT and its variation over time. * To learn the path used by packets to reach a destination. OAM in LPWAN is a little bit trickier since the bandwidth is limited and extra traffic added by OAM can introduce perturbation on regular transmission. Two scenarios can be investigated: * OAM coming from internet. In that case, the NGW should act as a "Manufacturer Usage Description for quarantined access to firmware", Michael Richardson, M. Ranganathan, 2020-11-02, The Manufacturer Usage Description is a tool to describe the limited access that a single function device such as an Internet of Things device might need. "Benchmarking Methodology for EVPN Multicasting", sudhin jacob, Vikram Nagarajan, 2020-10-27, This document defines methodologies for benchmarking IGMP proxy performance over EVPN-VXLAN. IGMP proxy over EVPN is defined in draft-ietf-bess-evpn-IGMP-mld-proxy-02, and is being deployed in data center networks. Specifically this document defines the methodologies for benchmarking IGMP proxy convergence, leave latency Scale,Core isolation, high availability and longevity. "Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, 2020-08-01, 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. "Receivers Guidance for Implementing Branded Indicators for Message Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw, 2020-08-01, This document is meant to assist receivers or other mailbox providers by providing guidance to implementing Brand Indicators for Message Identification (BIMI). This document is a companion to the main BIMI drafts which should first be consulted and reviewed. "A standard process to quarantine and restore IoT Devices", Michael Richardson, Jacques Latour, 2020-11-02, The Manufacturer Usage Description (MUD) is a tool to describe the limited access that a single function device such as an Internet of Things device might need. The enforcement of the access control lists described protects the device from attacks from the Internet, and protects the Internets from compromised devices. This document details a process which occurs when a device is detected to have violated the stated policy. The goal of these steps is to ensure that the device is correctly removed from operation, fixed, and if possible, restored to safe operation. This document does not define any new protocols, but provides context in which a number of existing protocols are to be used together. "Illustrations for SRv6 Network Programming", Clarence Filsfils, Pablo Camarillo, Zhenbin Li, Satoru Matsushima, Bruno Decraene, Dirk Steinberg, David Lebrun, Robert Raszuk, John Leddy, 2020-09-25, This document illustrates how SRv6 Network Programming [I-D.ietf-spring-srv6-network-programming] can be used to create interoperable and protected overlays with underlay optimization and service programming. "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip Hallam-Baker, 2021-01-13, 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-01-13, 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-01-07, 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. "The Per-Segment Service Instruction (PSSI) Option", Ron Bonica, 2020-10-09, This draft has been withdrawn.. "A One-Path Congestion Metric for IPPM", Joanna Dang, Jianglong Wang, Shinyoung Lee, Hongbo Yan, Liang Cheng, 2020-08-13, This memo defines a metric for one path congestion across Internet paths. The traditional mode evaluates network congestion based on the bandwidth utilization of the link. However, there is a lack of E2E path congestion that is truly service oriented. So A Path Congestion Metric is required. "Multi-Path Concurrent Measurement for IPPM", Joanna Dang, Jianglong Wang, Shinyoung Lee, Liang Cheng, 2020-08-13, This test method can test multi-paths concurrently from one edge node to another edge node. This document details Multi-Path Concurrent Measurement (MPCM). "Bidirectional Forwarding Detection (BFD) for EVPN Ethernet Segment Failover Use Case", Zheng Zhang, Yubao Wang, Greg Mirsky, 2020-11-15, This document introduces a method for fast switchover of Designated Forwarder for Ethernet Segment failover by using Bidirectional Forwarding Detection protocol. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Sun Kj, Hyunsik Yang, Jangwon Lee, Quang-Huy Nguyen, Younghan Kim, 2020-11-02, This draft describes considerations for benchmarking network performance in containerized infrastructures. In the containerized infrastructure, Virtualized Network Functions(VNFs) are deployed on 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 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, 2020-10-31, 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 in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)", Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor, 2020-11-01, 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. The data model includes configuration data and state data (status information and counters for the collection of statistics). "Encapsulation for BIER in Non-MPLS IPv6 Networks", Jingrong Xie, Liang Geng, Mike McBride, Rajiv Asati, Senthil Dhanaraj, Yongqing Zhu, Zhuangzhuang Qin, MooChang Shin, Gyan Mishra, Xuesong Geng, 2021-01-11, This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- MPLS IPv6 Networks using the IPv6 Destination Option extension header. This document updates RFC 8296. "Composite Keys and Signatures For Use In Internet PKI", Mike Ounsworth, Massimiliano Pala, 2020-07-28, 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 document defines the structures CompositePublicKey, CompositeSignatureValue, and CompositeParams, which are sequences of the respective structure for each component algorithm. This document also defines algorithms 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 algorithms are defined. "A YANG Data Model for Network Interconnect Tester Management", Vladimir Vassilev, 2020-09-05, This document introduces new YANG model for use in network interconnect testing containing modules for traffic generator and traffic analyzer. "Authentication-Results Registration for OpenPGP Signature Verification", Simon Ser, 2019-03-10, RFC 7601 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for PGP-related signature checks. "Considerations for ID/Location Separation Protocols in IPv6-based Vehicular Networks", Sun Kj, Younghan Kim, 2020-10-15, ID/Location separation protocols are proposed for scalable routing, enhancing mobility and privacy in IPv6-based vehicular networks. In IPv6-based vehicular networks, ID/Location separation architecture is expected to offer benefits. This document analyzes how ID/Location separation protocols can adjust into IP based vehicular networks and suggests requirements for efficient ID/Location separation in vehicular networks. "YANG data model for SFF", Ran Chen, Xufeng Liu, Huanan Chen, Wei Wei, Ting Ao, 2020-12-27, This document is to define the YANG data model for SFF configuration. "Encapsulation For MPLS Performance Measurement with Alternate Marking Method", Weiqiang Cheng, Xiao Min, Tianran Zhou, Ximing Dong, Yoav Peleg, 2020-09-08, This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on live traffic. "SRv6 Midpoint Protection", Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong Geng, 2020-10-15, 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, 2020-11-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. "Use of BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 networks", Jingrong Xie, Mike McBride, Senthil Dhanaraj, Liang Geng, Gyan Mishra, 2020-10-10, This draft defines the procedures and messages for using Bit Index Explicit Replication (BIER) for Multicast VPN Services in IPv6 networks using the BIER IPv6 encapsulation. It provides a migration path for Multicast VPN service using BIER MPLS encapsulation in MPLS networks to multicast VPN service using BIER IPv6 encapsulation (BIERv6) in IPv6 networks. "BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf, Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2020-07-26, The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out [I-D.ietf-grow-bmp-adj-rib-out]. By monitoring these BGP RIB's the full state of the network is visible, but how route-policies affect the route propagation or changes BGP attributes is still not. This document describes a method of using BMP to record the trace data on how BGP routes are (not) changed under the process of route policies. "BGP Flow Specification for SRv6", Zhenbin Li, Lei Li, Huaimo Chen, Christoph Loibl, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, 2020-12-01, This document proposes extensions to BGP Flow Specification for SRv6 for filtering SRv6 packets that match a sequence of conditions. "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde, 2020-10-30, Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. "Arm's Platform Security Architecture (PSA) Attestation Token", Hannes Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati, 2020-12-01, The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. At its core, the CWT (COSE Web Token) format is used and populated with a set of claims in a way similar to EAT (Entity Attestation Token). This specification describes what claims are used by PSA compliant systems. "Weighted HRW and its applications", satyamoh@cisco.com, Mankamana Mishra, Acee Lindem, Ali Sajassi, John Drake, 2020-12-08, Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. "On Media-Types, Content-Types, and related terminology", Carsten Bormann, 2020-08-18, There is a lot of confusion about media-types, content-types, and related terminology. This memo is an attempt at clearing it up, so we can use consistent terminology in CoRE and related specifications. It also defines some ABNF that can be used in these specifications. "BRSKI enrollment of with disconnected Registrars -- smarkaklink", Michael Richardson, Jacques Latour, 2020-11-02, This document details the mechanism used for initial enrollment using a smartphone of a BRSKI Registrar system. There are two key differences in assumption from [I-D.ietf-anima-bootstrapping-keyinfra]: that the intended registrar has Internet, and that the Pledge has no user-interface. This variation on BRSKI is intended to be used in the situation where the registrar device is new out of the box and is the intended gateway to the Internet (such as a home gateway), but has not yet been configured. This work is also intended as a transition to the Wi-Fi Alliance work on the Device Provisioning Protocol (DPP). "Urban Air Mobility Implications for Intelligent Transportation Systems", Fred Templin, 2021-01-04, Urban Air Mobility concerns the introduction of manned and unmanned aircraft within urban environments, while Intelligent Transportation Systems have traditionally considered only terrestrial vehicles operating on city streets and highways. This document considers the implications for introduction of low-altitude aircraft within urban environments operating in harmony with ground transportation. "Use cases for Remote Attestation common encodings", Michael Richardson, Carl Wallace, Wei Pan, 2020-11-02, This document details mechanisms created for performing Remote Attestation that have been used in a number of industries. The document initially focuses on existing industry verticals, mapping terminology used in those specifications to the more abstract terminology used by the IETF RATS Working Group. The document aspires to describe possible future use cases that would be enabled by common formats. "Autonomic setup of fog monitoring agents", Carlos Bernardos, Alain Mourad, 2020-11-19, 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. "EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan, Kiran Nagaraj, Wen Lin, Ali Sajassi, 2020-09-09, 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. "In Situ OAM Profiles", Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel, Tianran Zhou, Jennifer Lemon, 2020-08-05, 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, 2020-09-10, 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-01-13, 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. "SRv6 Implementation and Deployment Status", Satoru Matsushima, Clarence Filsfils, Zafar Ali, Zhenbin Li, Kalyani Rajaraman, 2020-12-17, This draft provides an overview of IPv6 Segment Routing (SRv6) deployment status. It lists various SRv6 features that have been deployed in the production networks. It also provides an overview of SRv6 implementation and interoperability testing status. "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, 2020-09-10, 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, 2020-11-02, This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory. "Mathematical Mesh 3.0 Part X: Considerations for Quantum Cryptanalysis Resistance", Phillip Hallam-Baker, 2020-11-02, 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. [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-quantum.html. "Mathematical Mesh 3.0 Part XIV: Considerations for Constrained Devices", Phillip Hallam-Baker, 2020-11-02, 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 [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- constrained.html. "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip Hallam-Baker, 2020-11-02, 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 VII: Security Considerations", Phillip Hallam-Baker, 2020-11-02, 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-01-13, 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-01-13, 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. "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2020-09-30, 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, 2020-11-24, This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media. "Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou, Lifen Zhou, 2020-10-26, 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). "In-Network Computing for App-Centric Micro-Services", Dirk Trossen, Chathura Sarathchandra, Michael Boniface, 2020-10-23, The application-centric deployment of 'Internet' services has increased over the past ten years with many millions of applications providing user-centric services, executed on increasingly more powerful smartphones that are supported by Internet-based cloud services in distributed data centres, the latter mainly provided by large scale players such as Google, Amazon and alike. This draft outlines a vision for evolving those data centres towards executing app-centric micro-services; we dub this evolved data centre as an AppCentre. Complemented with the proliferation of such AppCentres at the edge of the network, they will allow for such micro-services to be distributed across many places of execution, including mobile terminals themselves, while specific micro-service chains equal today's applications in existing smartphones. We outline the key enabling technologies that needs to be provided for such evolution to be realized, including references to ongoing IETF work in some areas. "BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs", John Drake, Adrian Farrel, Luay Jalil, Avinash Lingala, 2020-12-07, Future networks that support advanced services, such as those enabled by 5G mobile networks, envision a set of overlay networks each with different performance and scaling properties. These overlays are known as network slices and are realized over a common underlay network. In the context of IETF technologies, they are known as IETF network slices. In order to support IETF network slicing, as well as to offer enhanced VPN services in general, it is necessary to define a mechanism by which specific resources (links and/or nodes) of an underlay network can be used by a specific network slice, VPN, or set of VPNs. This document sets out such a mechanism for use in Segment Routing networks. "Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)", Derek Atkins, 2020-11-17, This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms. The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, WalnutDSA has not been endorsed by the IETF. WalnutDSA(TM) and Walnut Digital Signature Algorithm(TM) are trademarks of Veridify Security Inc.. "IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)", Parag Kaneriya, Rejesh Shetty, Shraddha Hegde, Ron Bonica, 2020-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. "Asymmetric IPv6 for Resource-constrained IoT Networks", Sheng Jiang, Guangpeng Li, Brian Carpenter, 2020-11-16, This document describes a new approach to IPv6 header compression for use in scenarios where minimizing packet size is crucial but routing performance must be maximised. "Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao, 2020-10-31, 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, 2020-11-15, 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, 2020-12-14, 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, 2020-10-30, 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 Parameters advertisement", Bruno Decraene, Chris Bowers, Jayesh J, Tony Li, Gunter Van de Velde, 2020-10-29, 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 SNP and/or Hello messages. This TLV may carry a set of parameters indicating the performance capacity to receive LSPs. "Guidelines for Internet Congestion Control at Endpoints", Gorry Fairhurst, 2020-11-17, This document is for discussion by the TSVWG. It provides guidance on the design of methods to avoid congestion collapse and to provide congestion control. Recommendations and requirements on this topic are distributed across many documents in the RFC series. This therefore seeks to gather and consolidate these recommendations in an annexe. Based on these specifications, and Internet engineering experience, the document provides input to the design of new congestion control methods in protocols. The present document is for discussion and comment by the IETF. If published, it plans to update or replace the Best Current Practice in BCP 41, which currently includes "Congestion Control Principles" provided in RFC2914. "BIER IPv6 Encapsulation (BIERv6) Support via IS-IS", Jingrong Xie, Aijun Wang, Gang Yan, Senthil Dhanaraj, Xuesong Geng, 2020-10-27, This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) with IPv6 encapsulation (BIERv6). "Preferred Path Loop-Free Alternate (pLFA)", Stewart Bryant, Uma Chunduri, Toerless Eckert, 2020-12-22, 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. "Multicast On-path Telemetry Solutions", Haoyu Song, Mike McBride, Greg Mirsky, Gyan Mishra, 2021-01-19, 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. "Deterministic Networking (DetNet) Controller Plane Framework", Andrew Malis, Xuesong Geng, Mach Chen, Fengwei Qin, Balazs Varga, 2020-11-18, This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements that will be basis for Detnet controller plane solution documents. "PCEP Operational Clarification", Mike Koldychev, Siva Sivabalan, Mahendra Negi, Diego Achaval, Hari Kotni, 2020-08-26, This document is meant to provide better clarity about how PCEP operates and hence to facilitate better 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 to facilitate this, such as the LSP-DB and the ASSO-DB. "The Some Congestion Experienced ECN Codepoint", Jonathan Morton, Peter Heist, Rodney Grimes, 2020-11-02, 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. "QUIC for SATCOM", Nicolas Kuhn, Gorry Fairhurst, John Border, Stephan Emile, 2020-10-30, QUIC has been designed for use across Internet paths. Initial designs of QUIC focused on common deployment scenarios for web traffic. This document focuses on the performance when using a path with a large Bandwidth-Delay Product (BDP). A large BDP path can result from using a satellite communication (SATCOM) system. The BDP is also high for paths where a satellite network segment is combined with other network technologies (Ethernet, cable modems, WiFi, cellular, radio links, etc), resulting in more complex characteristics. These path characteristics have implications on the efficiency of the network traffic and unless considered in a design can impact the end-to-end quality of experience by the transport service. This memo identifies the characteristics of a SATCOM link that impact the operation of the QUIC transport protocol. It proposes regression tests to evaluate QUIC over SATCOM links. It discusses how to ensure acceptable protocol performance. "Carrying SID Algorithm information in PCE-based Networks.", Alexej Tokar, Samuel Sidor, Siva Sivabalan, Shuping Peng, Mahendra Negi, 2020-09-02, 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. "Main logging schema for qlog", Robin Marx, 2020-11-02, 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 and HTTP/3 event definitions for qlog", Robin Marx, 2020-11-02, This document describes concrete qlog event definitions and their metadata for QUIC and HTTP/3-related events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. "Inter-Domain Multicast Deployment using BIERv6", Liang Geng, Jingrong Xie, Mike McBride, Gang Yan, Xuesong Geng, 2020-10-27, Bit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces an approach to use IPv6 extension header to carry BIER header with IPv6 unicast address as destination address. It provides the ability to replicate a packet from one router to other routers in a different domain as well as routers in the same domain. This document introduces the techniques for multicast deployment across multiple domains using BIERv6, and demonstrate how BIERv6 is beneficial for such deployment. "Operations, Administration and Maintenance (OAM) features for RAW", Fabrice Theoleyre, Georgios Papadopoulos, Greg Mirsky, 2020-10-25, Some critical applications may use a wireless infrastructure. However, wireless networks exhibit a bandwidth of several orders of magnitude lower than wired networks. Besides, wireless transmissions are lossy by nature; the probability that a packet cannot be decoded correctly by the receiver may be quite high. In these conditions, guaranteeing the network infrastructure works properly is particularly challenging, since we need to address some issues specific to wireless networks. This document lists the requirements of the Operation, Administration, and Maintenance (OAM) features recommended to construct a predictable communication infrastructure on top of a collection of wireless segments. This document describes the benefits, problems, and trade-offs for using OAM in wireless networks to achieve Service Level Objectives (SLO). "Using GOST ciphers in ESP and IKEv2", Valery Smyslov, 2020-10-26, 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, 2020-10-26, 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]. "Observe Notifications as CoAP Multicast Responses", Marco Tiloca, Rikard Hoeglund, Christian Amsuess, Francesca Palombini, 2020-11-02, 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 to all the clients observing a same target resource. This document defines how a CoAP server sends observe notifications as response messages over multicast, by 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 from the CoAP server to the multiple observer clients. "Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework", Marco Tiloca, Rikard Hoeglund, Ludwig Seitz, Francesca Palombini, 2020-11-02, 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 signing 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. "IS-IS Extensions to Support Transport Network Slices using Segment Routing", Yongqing Zhu, Ran Chen, Shaofu Peng, Fengwei Qin, 2020-09-04, [I-D.nsdt-teas-ns-framework] provides a framework of transport slices. This draft describes the IS-IS extensions required to support transport slices using Segment Routing. "YANG Data Model for p2mp sr policy", Hooman Bidgoli, Daniel Voyer, Rishabh Parekh, Tarek Saad, Tanmoy Kundu, 2020-10-30, SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document defines a YANG data model for SR P2MP Policy Configuration and operation. "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu, 2020-10-31, 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, 2020-10-31, 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, 2020-12-21, 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. "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng, Greg Mirsky, Yubao Wang, 2020-08-13, This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service. "5G transport network benchmarking", Luis Contreras, Juan Rodriguez, Lourdes Luque, 2020-11-02, New 5G services are starting to be deployed in operational networks, leveraging in a number of novel technologies and architectural concepts. The purpose of this document is to overview the implications of 5G services in transport networks and to provide guidance on bechmarking of the infratructures supporting those services. "Distributed SFC control for fog environments", Carlos Bernardos, Alain Mourad, 2021-01-18, 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. "Protocol Assisted Protocol (PAP)", Zhenbin Li, Shuanglong Chen, Yunan Gu, 2020-11-02, For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP(BGP Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PAP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues. "Encapsulation of Path Segment in SRv6", Cheng Li, Weiqiang Cheng, Zhenbin Li, Dhruv Dhody, 2020-10-30, 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. This document defines the encoding of Path Segment in SRv6 networks. "BGP Request for Candidate Paths of SR TE Policies", Zhenbin Li, Lei Li, Huaimo Chen, Yanhe Fan, Xufeng Liu, Lei Liu, 2020-10-03, An SR Policy is a set of candidate paths. The headend of an SR Policy may learn multiple candidate paths for an SR Policy via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document defines extensions to BGP for the headend to request BGP speaker (controller) for advertising the candidate paths. "Network Programming extension: SRv6 uSID instruction", Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Daniel Voyer, Israel Meilik, Keyur Patel, Wim Henderickx, Prem Jonnalagadda, David Melman, Yisong Liu, Jim Guichard, 2020-11-02, The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: o The SRv6 Control Plane is leveraged without any change o The SRH dataplane encapsulation is leveraged without any change o Any SID in the SID list can carry micro segments o Based on the Compressed SRv6 Segment List Encoding in SRH "PCEP extensions for p2mp sr policy", Hooman Bidgoli, Daniel Voyer, Saranya Rajarathinam, Ehsan Hemmati, Tarek Saad, Siva Sivabalan, 2020-10-30, 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. "Multicast in L3VPNs Signaled by EVPN SAFI", Zhaohui Zhang, Wen Lin, Jorge Rabadan, 2020-10-13, [ietf-bess-evpn-prefix-advertisement] specifies an EVPN SAFI Type-5 route that can be used to signal L3VPNs. This document specifies procedures for multicast in such an L3VPN. "Describing Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2020-11-02, 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. "Operational Considerations for use of DNS in IoT devices", Michael Richardson, 2020-09-22, 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 } "HTTP Transport Authentication", David Schinazi, 2020-09-09, The most common existing authentication mechanisms for HTTP are sent with each HTTP request, and authenticate that request instead of the underlying HTTP connection, or transport. While these mechanisms work well for existing uses of HTTP, they are not suitable for emerging applications that multiplex non-HTTP traffic inside an HTTP connection. This document describes the HTTP Transport Authentication Framework, a method of authenticating not only an HTTP request, but also its underlying transport. "Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/ Traceroute", Nagendra Nainar, Carlos Pignataro, Zafar Ali, Clarence Filsfils, Tarek Saad, 2020-10-29, 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. "EVPN Interoperability Modes", Lukas Krattiger, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, 2020-07-27, 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. "5G Wireless Wireline Convergence User Plane Encapsulation (5WE)", Dave Allan, Donald Eastlake, David Woolley, 2020-10-01, As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the RFC 2516 PPPoE data packet encapsulation. "Indication of Local DNS Privacy Service During User Access", Zhiwei Yan, Guanggang Geng, Yang Liu, Xinchang Zhang, Xiaomin Zhu, 2020-12-13, This document aims to support the indication of privacy service capability of recursive resolver during the end-user accesses the network. "SRv6 for Inter-Layer Network Programming", Jie Dong, Zongpeng Du, 2020-10-31, This document defines a new SRv6 network function which can be used for SRv6 inter-layer network programming. It is a variant of the End.X function. Instead of pointing to an L3 adjacency, this function points to an underlay interface. Such a interface can stand for a underlay link or path/connection between two routers, which may be invisible in the L3 topology. "PCEP Extension for SR-MPLS Entropy Label Position", Shaofu Peng, Quan Xiong, Fengwei Qin, 2020-08-12, This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks. "Definition of new tags for relations between RFCs", Mirja Kuehlewind, Suresh Krishnan, 2020-11-02, 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. "PCE TE Constraints for Network Slicing", Shaofu Peng, Quan Xiong, Fengwei Qin, 2020-08-31, This document proposes a set of extensions for PCEP to support the TE constraints of network slicing during path computation, e.g, IGP instance, virtual network, specific application, color template and FA-id etc. "Software Version Capability for BGP", Donatas Abraitis, 2020-08-29, In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. "Maintaining CCNx or NDN flow balance with highly variable data object sizes", David Oran, 2020-08-24, Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. "Extensible Provisioning Protocol (EPP) Industrial Internet Identifier Mapping", Yuying Chen, Jiagui Xie, Zhiping Li, Zhipeng Fan, 2020-08-18, This document describes an Extensible Provisioning Protocol (EPP)mapping for the provisioning and management of Industrial Internet Identifiers. Specified in XML, the mapping defines EPP command syntax and semantics as applied to identifiers. "Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish, Philip Shilane, 2020-12-21, 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, 2020-10-27, 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. "ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", Paul Yang, 2020-09-27, This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLSv1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, and so this document provides a description of how to use the SM algorithms with TLSv1.3 and specifies a profile of TLSv1.3 so that implementers can produce interworking implementations. "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", Dorothy 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. "Packet Network Slicing using Segment Routing", Shaofu Peng, Ran Chen, Greg Mirsky, Fengwei Qin, 2020-10-20, This document presents a mechanism aimed at providing a solution for network slicing in the transport network for 5G services. The proposed mechanism uses a unified administrative instance identifier to distinguish different virtual network resources for both intra- domain and inter-domain network slicing scenarios. Combined with the segment routing technology, the mechanism could be used for both best-effort and traffic engineered services for tenants. "YANG Data Model for Dynamic Flooding", Srinath Dontula, Tony Li, Athar Siddiqui, 2020-09-28, This document defines YANG data models that can be used to configure and manage Dynamic Flooding for IS-IS and OSPF. "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael Richardson, 2020-09-24, 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 "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2020-10-21, 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. "New Cryptographic Algorithms for HIP", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2021-01-20, 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, 2020-11-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, 2020-11-18, 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, Daniel Voyer, Satoru Matsushima, Zhenbin Li, 2021-01-11, 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 [I-D.ietf-spring-srv6-network-programming] 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, Christopher Wood, 2020-12-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. "Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security", Valery Smyslov, 2020-08-03, 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, which allows to extend it on the initial IKEv2 SA. "MPLS Data Plane Encapsulation for In-situ OAM Data", Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak, 2021-01-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), including Segment Routing (SR) with MPLS data plane (SR-MPLS). "Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2020-11-02, 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, 2020-10-09, 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 fulfil 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, 2020-10-26, 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, 2020-12-29, 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 (PUA), utilized to detect a link or node down event and signal the RIB that the event has occurred to force immediate control plane convergence. "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng, Greg Mirsky, Yubao Wang, 2020-08-14, This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service. "Lzip Compressed Format and the application/lzip Media Type", Antonio Diaz, 2020-10-23, Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses a simplified form of the 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, 2020-09-12, 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, 2020-12-14, 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. "In-situ OAM Deployment", Frank Brockners, Shwetha Bhandari, daniel.bernier@bell.ca, 2020-09-07, 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 provides a framework for IOAM deployment and provides best current practices. "Use Cases and Requirements for Web Packages", Jeffrey Yasskin, 2020-07-27, This document lists use cases for signing and/or bundling collections of web pages, and extracts a set of requirements from them. Note to Readers Discussion of this draft takes place on the ART area mailing list (art@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=art (https://mailarchive.ietf.org/arch/search/?email_list=art). The source code and issues list for this draft can be found in https://github.com/WICG/webpackage (https://github.com/WICG/ webpackage). "Advertising p2mp policies in BGP", Hooman Bidgoli, Daniel Voyer, Andrew Stone, Rishabh Parekh, Serge Krier, Arvind Venkateswaran, 2020-10-29, 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 two new route types within this NLRI, one for P2MP policy and its candidate paths that need to be programmed on the Root node and another for the replication segment and 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. "Internet Services over ICN in 5G LAN Environments", Dirk Trossen, Sebastian Robitzsch, University Essex, Mays AL-Naday, Janne Riihijarvi, 2020-10-01, In this draft, we provide architecture and operations for enabling Internet services over ICN over (5G-enabled) LAN environments. Operations include ICN API to upper layers, HTTP over ICN, Service Proxy Operations, ICN Flow Management, Name Resolution, Mobility Handling, and Dual Stack Device Support. "Compressed Routing Header (CRH) Helper Option", Xing Li, Congxiao Bao, Eddie Ruan, Ron Bonica, 2020-10-26, 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. "PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, 2020-10-27, Current PCEP standards allow only one intended and/or actual path to be present in a PCEP report or update. Applications that require multipath support such as SR Policy require an extension to allow signaling multiple intended and/or actual paths within a single PCEP message. This document introduces such an extension. Encoding of multiple intended and/or actual paths is done by encoding multiple Explicit Route Objects (EROs) and/or multiple Record Route Objects (RROs). A special separator object is defined in this document, to facilitate this. This mechanism is applicable to SR-TE and RSVP-TE and is dataplane agnostic. "Architecture Discussion on SRv6 Mobile User plane", Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali, 2020-11-02, This document discusses a 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, Jing Xu, 2020-10-29, 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, 2020-10-29, 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 managing 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. "Bulk Subscription to YANG Event Notification", Qin WU, Peng Liu, Yuexia Fu, 2020-10-29, This document defines a YANG data model and associated mechanism that allows subscriber applications to bulk subscribe to publishers' event streams based on bundle group information such as bundle size and bundle latency. This allows the publishers to report multiple notifications in a single bundling message. "IS-IS YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Stephane Litkowski, Yingzhen Qu, 2021-01-05, This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and IS-IS Application-Specific Link Attributes as defined in RFC 8919. "Color Operation with BGP Label Unicast", Louis Chan, 2020-08-31, 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. There is a major change of protocol format starting from this updated draft. "Performance Measurement for Geneve", Xiao Min, Greg Mirsky, Santosh Pallagatti, 2020-11-23, 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. "Self describing data Node tag capability", Qin WU, Qiufang Ma, Peng Liu, Yuexia Fu, 2020-10-29, Before a client application subscribes to updates from a datastore, server capabilities related to "Subscription to YANG Datastores" can be advertised using YANG Instance Data format. These server capabilities can be documented at implement time or reported at run- time. This document proposes a YANG module for self describing data Object tag capability which augments system capabilities model and provide additional self describing data node attributes associated with node selectors within per-node capabilities. "A YANG Data Model for Client Signal Performance Monitoring", Haomian Zheng, Italo Busi, Zheng Yanlei, 2021-01-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. "Requirements for IoT Services based on Visible Light Communications", Seok Koh, Cheol-Min Kim, 2020-11-17, This document describes the requirements for IoT Services based on Visible Light Communication (VLC) to effectively provide IoT services in the VLC-based networks. This document includes the overview of VLC technology and the concepts of VLC-based IoT services, and the requirements for IoT services in the VLC-based networks. "Context-Aware Navigation Protocol for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Zhong Xiang, Zeung Kim, 2020-11-02, 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, 2020-11-02, This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks. "SRv6 Deployment Consideration", Hui Tian, Feng Zhao, Chongfeng Xie, Tong Li, Jichun Ma, Robbins Mwehair, Edmore Chingwena, Shuping Peng, Zhenbin Li, Yaqun Xiao, 2021-01-10, SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced. "Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang, Aijun Wang, Shunwan Zhuang, 2020-09-10, BGP Flowspec mechanism [RFC5575] [I-D.ietf-idr-rfc5575bis] 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-01-18, 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, 2020-11-02, This document describes a YANG data model for managing and controlling IETF network slices, defined in [I-D.nsdt-teas-ietf-network-slice-definition]. "Service Assurance for Intent-based Networking Architecture", Benoit Claise, Jean Quilbeuf, Diego Lopez, Daniel Voyer, Thangam Arumugam, 2021-01-02, This document describes an architecture for Service Assurance for Intent-based Networking (SAIN). This architecture aims at assuring that service instances are correctly running. As services rely on multiple sub-services by the underlying network devices, getting the assurance of a healthy service is only possible with a holistic view of network devices. 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. "Communicating Warning Information in HTTP APIs", Andre Cedik, Erik Wilde, 2020-09-23, This document defines a new HTTP field Content-Warning and a standard response format for representing warning information in HTTP APIs. Note to Readers This draft should be discussed on the rfc-interest mailing list (). Online access to all versions and files is available on GitHub (). "Transport Protocol Issues of In-Network Computing Systems", Ike Kunze, Klaus Wehrle, Dirk Trossen, 2020-11-02, Today's transport protocols offer a variety of functionality based on the notion that the network is to be treated as an unreliable communication medium. Some, like TCP, establish a reliable connection on top of the unreliable network while others, like UDP, simply transmit datagrams without a connection and without guarantees into the network. These fundamental differences in functionality have a significant impact on how COIN approaches can be designed and implemented. Furthermore, traditional transport protocols are not designed for the multi-party communication principles that underlie many COIN approaches. This document raises several questions regarding the use of transport protocols in connection with COIN. "IETF Network Slice use cases and attributes for Northbound Interface of controller", Luis Contreras, Shunsuke Homma, Jose Ordonez-Lucena, 2020-10-30, The transport network is an essential component in the end-to-end delivery of services and, consequently, with the advent of network slicing it is necessary to understand what could be the way in which the transport network is consumed as a slice. This document analyses the needs of potential IETF network slice customers (i.e., use cases) in order to identify the functionality required on the North Bound Interface (NBI) of a IETF network slice controller for satisfying such IETF network slice requests. "IS-IS Flooding Scale Considerations", Les Ginsberg, Peter Psenak, Acee Lindem, Tony Przygienda, 2020-10-19, 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, 2020-11-02, This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. 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, 2020-11-02, 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 raises an initial approach towards the use of ALTO to provide such information and assist in the selection of proper execution environments. "YANG Modules for Service Assurance", Benoit Claise, Jean Quilbeuf, Paolo Lucente, Paolo Fasano, Thangam Arumugam, 2021-01-02, This document proposes YANG modules for the Service Assurance for Intent-based Networking Architecture. "TLS 1.3 Extended Key Schedule", Jonathan Hoyland, Christopher Wood, 2020-12-03, TLS 1.3 is sometimes used in situations where it is necessary to inject extra key material into the handshake. This draft aims to describe methods for doing so securely. This key material must be injected in such a way that both parties agree on what is being injected and why, and further, in what order. "Bijective MAC for Constraint Nodes", Pascal Urien, 2020-12-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, 2020-09-03, 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-01-21, 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, 2020-11-29, 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, 2020-11-02, 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, 2020-10-04, 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. "Network Address Translation Support for QUIC", Martin Duke, 2020-07-29, Network Address Translators (NATs) are widely deployed to share scarce public IPv4 addresses among multiple end hosts. They overwrite IP addresses and ports in IP packets to do so. QUIC is a protocol on top of UDP that provides transport-like services. QUIC is better-behaved in the presence of NATs than older protocols, and existing UDP NATs should operate without incident if unmodified. QUIC offers additional features that may tempt NAT implementers as potential optimizations. However, in practice, leveraging these features will lead to new connection failure modes and security vulnerabilities. "Data Aggregation in IPv6-based Vehicular Networks", Zhiwei Yan, Jong-Hyouk Lee, Jaehoon Jeong, Yong-Jin Park, Hidenori Nakazato, 2020-11-15, 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. "The Base58 Encoding Scheme", Satoshi Nakamoto, Manu Sporny, 2020-10-31, This document specifies the base 58 encoding scheme, including an introduction to the benefits of the approach, the encoding and decoding algorithm, alternative alphabets, and security considerations. "IGP Flexible Algorithm Optimazition for Netwrok Slicing", Shaofu Peng, Ran Chen, Greg Mirsky, 2020-09-05, IGP Flex Algorithm 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. This document extends the use of the IGP Flex Algorithm to to be more suitable for network slicing scenarios. "Operational Considerations for BRSKI Registrar", Michael Richardson, Jie Yang, 2020-07-29, This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. "Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)", Laura Corcoran, Michael Jenkins, 2020-08-17, 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. "Internationalization for the NFSv4 Protocols", David Noveck, 2020-09-06, 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 RFC5661. "Attribution Option for Extension Header Insertion", Tom Herbert, 2020-10-29, This document defines an "Attribution Option" that provides attribution for IPv6 extension headers, Hop-by-Hop options, or Destination options that are inserted by intermediate nodes in the delivery path of a packet. The purpose of this option is twofold: first it identifies the extension headers or options that have been inserted, secondly it attributes the inserted extension headers or options to the node responsible for inserting them. "RPKI validated cache Update in SLURM over HTTPs (RUSH)", Di Ma, Hanbing Yan, Melchior Aelmans, 2020-11-17, 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, 2020-12-19, 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. "Industrial Internet Identifier Node (IIIN) Data Escrow Specification", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2020-12-19, 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. "IGP Flexible Algorithm with L2bundles", Yongqing Zhu, Shaofu Peng, Ran Chen, Greg Mirsky, 2020-12-07, IGP Flex Algorithm 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. This document describes how to create Flex-algo plane with L2bundles scenario. "JSON serialization for Web Linking", Evert Pot, Gabriel Sullice, 2020-11-01, This specification defines a serialization of Web Linking [RFC8288] in the JSON [RFC8259] format. "Resource Allocation Model for Hybrid Switching Networks", Weiqiang Sun, Junyi Shao, Weisheng Hu, 2020-12-19, 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. "Inter-domain Network Slicing via BGP-LU", Ran Chen, Chunning Dai, Shaofu Peng, 2021-01-12, This document aims to solve inter-domain network slicing problems using existing technologies. It attempts to establish multiple BGP- LU LSPs of different colors for a prefix to stitch multiple network segments. "Threshold Modes in Elliptic Curves", Phillip Hallam-Baker, 2021-01-13, 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 . "Threshold Signatures in Elliptic Curves", Phillip Hallam-Baker, 2021-01-13, A Threshold signature scheme is described. The signatures created are computationally indistinguishable from those produced using the Ed25519 and Ed448 curves as specified in RFC8032 except in that they are non-deterministic. Threshold signatures are a form of digital signature whose creation requires two or more parties to interact but does not disclose the number or identities of the parties involved. 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 . "Delegated Authority for Bootstrap Voucher Artifacts", Michael Richardson, Jie Yang, 2020-09-18, 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 [I-D.ietf-anima-bootstrapping-keyinfra] Manufacturer Authorized Signing Authority (MASA). "OSPF Graceful Restart Enhancements", Sami Boutros, Ankur Dubey, Vijayalaxmi Basavaraj, Acee Lindem, 2020-12-27, This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187. "MASQUE Obfuscation", David Schinazi, 2020-09-09, This document describes MASQUE Obfuscation. MASQUE Obfuscation is a mechanism that allows co-locating and obfuscating networking applications behind an HTTPS web server. The currently prevalent use-case is to allow running a proxy or VPN server that is indistinguishable from an HTTPS server to any unauthenticated observer. We do not expect major providers and CDNs to deploy this behind their main TLS certificate, as they are not willing to take the risk of getting blocked, as shown when domain fronting was blocked. An expected use would be for individuals to enable this behind their personal websites via easy to configure open-source software. This document is a straw-man proposal. It does not contain enough details to implement the protocol, and is currently intended to spark discussions on the approach it is taking. 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/DavidSchinazi/masque-drafts. "Passive Interface Attribute", Aijun Wang, Zhibo Hu, Gyan Mishra, 2020-11-14, This document describes the mechanism that can be used to differentiate the passive interfaces from the normal interfaces within ISIS or OSPF domain. "(strong) AuCPace, an augmented PAKE", Bjoern Haase, 2020-08-07, 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. "IGP Extensions for Segment Routing Service Segment", Liu Yao, Zheng Zhang, Yongqing Zhu, 2021-01-21, This document defines extensions to the link-state routing protocols (IS-IS and OSPF) in order to carry service segment information via IGP. "Context Label for MPLS EVPN", Yubao Wang, Bing Song, 2020-08-20, EVPN is designed to provide a better VPLS service than [RFC4761] and [RFC4762], and EVPN indeed introduced many new features which couldn't be achieved in those old VPLS implementions. But EVPN didn't inherit all features of old VPLS, and a few issues arises for EVPN only. Some of these issues can be imputed to the MP2P nature of EVPN labels. The PW label in old VPLS is a label for P2P VC, so it contains more context than a identifier in dataplane for it's VSI instance.But the EVPN label just identifies it's VSI instnace and it can't stand for the ingress PE in dataplane. So the following issues arises with MPLS EVPN service: * MPLS EVPN statistics can't be done per ingress PE. * MPLS EVPN can't support hub/spoke use case which the spoke PE can "Analysis Framework For Extensions of SRv6 Encapsulation", Clarence Filsfils, Darren Dukes, Keyur Patel, 2020-07-27, This document provides a framework for analysis of multiple proposals to extend SRv6 encapsulation with the objective of minimizing encapsulation size or leveraging legacy equipment. It defines relevant metrics to evaluate each proposal. "Stateless and Scalable Network Slice Identification for SRv6", Clarence Filsfils, Francois Clad, Pablo Camarillo, Kamran Raza, 2021-01-13, 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, 2020-09-11, 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. "Authorized update to MUD URLs", Michael Richardson, Jie Yang, Eliot Lear, 2020-11-02, 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 "BGP-LS Extensions for Transport Slice", Shaofu Peng, 2020-09-02, [I-D.peng-teas-network-slicing] defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This draft defines extensions to BGP-LS protocol in order to advertise the information of the transport slice. "Sender Control of Acknowledgement Delays in QUIC", Jana Iyengar, Ian Swett, 2020-11-02, This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . "BGP based Virtual Private Network (VPN) Services over SRm6 enabled IPv6 networks", Srihari Sangli, Ron Bonica, 2020-09-07, This document defines BGP protocol extensions for encoding and carrying SRm6 Tunnel Payload Forwarding information (TPF) to support Virtual Private Network services. This is applicable when the VPN services are offered in a SRm6 enabled IPv6 network such that the VPN payload is transported over IPv6. The Tunnel Payload Information is encoded in the IPv6 Destination Option Header in the IPv6 data packets. "Changing the Default QUIC ACK Policy", Gorry Fairhurst, Ana Custura, Tom Jones, 2020-09-14, Acknowledgement packets (ACKs) are used by transport protocols to confirm the delivery of packets, and their reception is used in a variety of other ways (to measure path round trip time, to gauge path congestion, etc). However, the transmission of ACKs also consumes resources at the receiver, forwarding resource in the network and processing resources at the sender. On network paths with significant path asymmetry, transmission of ACKs can limit the available throughput or can reduce the efficient use of network capacity. This occurs when the return capacity is significantly more constrained than the forward capacity, and/or the cost of transmission per packet is a significant component of the total transmission cost. In these cases, reducing the ratio of ACK packets to data packets can improve link utilisation and reduce link transmission costs. It can also reduce processing overhead at the sender and receiver. This document proposes a change to the default acknowledgement policy of the QUIC transport protocol to improve performance over paths with appreciable asymmetry. "The Grant Negotiation and Authorization Protocol", Dick Hardt, 2020-08-15, Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol may be extended on many dimensions. "Point-to-Multipoint Transport Using Chain Replication in Segment Routing", Yimin Shen, Zhaohui Zhang, Rishabh Parekh, Hooman Bidgoli, Yuji Kamite, 2020-10-21, 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, 2020-11-02, 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). Note to Readers Source for this draft and an issue tracker can be found at https://github.com/EricssonResearch/ace-ake-authz (https://github.com/EricssonResearch/ace-ake-authz). "Using GOST algorithms in IKEv2", Valery Smyslov, 2020-08-26, 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, Fengwei Qin, Guangming Yang, 2020-11-02, 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 in 5G, 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 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, 2020-11-02, 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 network infrastructure. A VTN can be used as the underlay for one or a group of VPNs to provide enhanced VPN (VPN+) services. In packet forwarding, some fields in data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed. This document proposes a new option type to carry VTN ID in an IPv6 extension headers to identify the Virtual Transport Network (VTN) the packet belongs to. The procedure for processing of the VTN option is also specified. "Generalized SRv6 Network Programming", Weiqiang Cheng, Zhenbin Li, Cheng Li, Chongfeng Xie, Cong Li, Hui Tian, Feng Zhao, 2020-09-10, As the deployment of SRv6, some new requirements are proposed, such as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. Therefore, it is necessary to consider other types of segments or sub-paths in the end-to-end SRv6 network programming. This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in a SRH, called Generalized SRH (G-SRH). These Segments can be called Generalized Segment, and the ID can be Generalized Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. This document also defines the mechanisms of Generalized SRv6 Networking Programming and the requirements of related protocol extensions of control plane and data plane. "Generalized Segment Routing Header", Zhenbin Li, Cheng Li, Weiqiang Cheng, Chongfeng Xie, Li Cong, Hui Tian, Feng Zhao, 2020-08-13, Generalized SRv6 network programming defines the enhanced mechanisms of SRv6 to encode SRv6 SIDs, Compressed SIDs and even the MPLS labels or IPv4 tunnel information in a single SRH. This type of SRH is called Generalized SRH (G-SRH), which can reduce the overhead of SRv6 and also provide more flexibility for network programming. This document defines the encapsulation and packet processing of G-SRH. "BGP Extension for SR-MPLS Entropy Label Position", Liu Yao, Shaofu Peng, 2020-08-21, This document proposed an extension for BGP to configure the entropy label position for SR-MPLS networks. "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, Tony Whyman, 2021-01-01, Mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, enterprise wireless devices, 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 therefore needed for coordination with the network-based mobility service. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. "SDP Mapping into HTTP structured headers", James Gruessing, 2020-08-14, This document specifies a HTTP header based representation of the Session Description Protocol which can be used in describing media being negotiated or delivered via HTTP. Note to Readers _RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at https://github.com/fiestajetsam/draft-gruessing-sdp-http (https://github.com/fiestajetsam/draft-gruessing-sdp-http). "Quic Timestamps For Measuring One-Way Delays", Christian Huitema, 2020-08-10, The TIME_STAMP frame can be added to Quic packets when one way delay measurements is useful. The timestamp is set to the number of microseconds from the beginning of the connection to the time at which the packet is sent. The draft defines the "enable_time_stamp" transport parameter for negotiating the use of this extension frame, and a new frame types for the time_stamped frame. "Adaptive Subscription to YANG Notification", Qin WU, Wei Song, Peng Liu, Qiufang Ma, 2021-01-20, 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 publishers automatically adjust the volume of telemetry traffic sent from publisher to the receivers. "Telemetry Data Export capability", Qin WU, Qiufang Ma, Peng Liu, 2021-01-20, This document proposes a YANG module for telemetry data export capabilities which augments system Capabilities model and provides additional telemetry data export attributes associated with system capabilities for transport dependent capability advertisement. "Approaches on Supporting IOAM in IPv6", Haoyu Song, Zhenbin Li, Shuping Peng, Jim Guichard, 2021-01-04, It has been proposed to encapsulate IOAM tracing option data fields in IPv6 HbH options header. However, due to size of the trace data and the extension header location in the IPv6 packets, the proposal creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require in-network processing. We propose several alternative approaches to address this challenge, including separating the IOAM trace data to a different extension header, using the postcard-based telemetry (e.g., IOAM DEX) instead, and applying the segment IOAM trace export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach and hope to foster standard convergence and industry adoption. "DHCP and Router Advertisement Options for Encrypted DNS Discovery", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook, Tommy Jensen, 2021-01-22, 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 port number to reach such encrypted DNS servers. The discovery of DNS-over-HTTPS URI Templates is also discussed. "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Christian Amsuess, 2020-11-02, Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. "Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng, Daniel Voyer, Cong Li, Liang Geng, Chang Cao, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2020-09-06, 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 (e.g. 5G) 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 characteristic information such as application identification and its network performance requirements is carried in the packet encapsulation in order to facilitate service provisioning, perform application-level traffic steering and network resource adjustment. "Problem Statement and Use Cases of Application-aware Networking (APN)", Zhenbin Li, Shuping Peng, Daniel Voyer, Chongfeng Xie, Peng Liu, Zhuangzhuang Qin, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2020-09-06, 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. However, network operators are typically unaware of which applications are traversing their network infrastructure, which means that only coarse-grained services can be provided to users. As a result, network operators are only evolving their infrastructure to be large but dumb pipes without corresponding revenue increases that might be enabled by differentiated service treatment. 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. Adding application knowledge to the network layer allows applications to specify finer granularity requirements to the network operator. This document analyzes the existing problems caused by lack of application awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) architecture. "Enhanced Performance Delay and Liveness Monitoring in Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Navin Vaghamshi, Moses Nagarajah, Richard Foote, 2020-09-26, 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 Delay and Liveness Monitoring (PDLM) in Segment Routing networks. The procedure leverages the probe messages compatible with the delay measurement message formats defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP)) and RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and is applicable to end-to-end SR Paths including SR Policies for both SR-MPLS and SRv6 data planes. "Announcing Supported Authentication Methods in IKEv2", Valery Smyslov, 2020-09-09, 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 P, Ollie Whitehouse, 2021-01-13, Indicators of Compromise (IoCs) are an important technique in attack defence (often called cyber defence). This document outlines the different types of IoC, their associated benefits and limitations, and discusses their effective use. It also contextualises the role of IoCs in defending against attacks through describing a recent case study. This draft does not pre-suppose where IoCs can be found or should be detected - as they can be discovered and deployed in networks, endpoints or elsewhere - rather, engineers should be aware that they need to be detectable (either by endpoints, security appliances or network-based defences, or ideally all) to be effective. The purpose of this draft is to document both the operational issues, but also the best practices associated with use of IoCs today. This draft provides a foundation for proposals 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, 2020-07-27, 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. "Textual Analysis Methodology for Security Considerations Sections", Mark McFadden, Alan Mills, 2020-09-09, [RFC3552] provides guidance to authors in crafting RFC text on Security Considerations. The RFC is more than fifteen years old. With the threat landscape and security ecosystem significantly changed since the RFC was published, RFC3552 is a candidate for update. This draft proposes that, prior to drafting an update to RFC3552, an examination of recent, published Security Considerations sections be carried out as a baseline for how to improve RFC3552. It suggests a methodology for examining Security Considerations sections in published RFCs and the extraction of both quantitative and qualitative information that could inform a revision of the older guidance. It also reports on a recent experiment on textual analysis of sixteen years of RFC Security Consideration sections. "Inserting, Processing And Deleting IPv6 Extension Headers", Ron Bonica, Tatuya Jinmei, 2020-08-30, This document provides guidance regarding the processing, insertion and deletion of IPv6 extension headers. It updates RFC 8200. "BGP Extensions for Unified SID in TE Policy", Liu Yao, Shaofu Peng, 2020-11-23, This document defines extensions to BGP in order to advertise Unified SIDs in SR-TE policies. "A User-Focused Internet Threat Model", Dominique Lazanski, 2021-01-07, 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, 2020-11-02, 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, 2020-09-09, 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, 2020-09-09, 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, 2020-09-09, This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. "Egress Protection for Segment Routing (SR) networks", Shraddha Hegde, Wen Lin, Shaofu Peng, 2020-11-15, This document specifies a Fast Reroute(FRR) mechanism for protecting IP/MPLS services that use Segment Routing (SR) paths for transport against egress node and egress link failures. The mechanism is based on egress protection framework described in [RFC8679]. The egress protection mechanism can be further simplified in Segment Routing networks with anycast SIDs and anycast Locators. This document addresses all kinds of networks that use Segment Routing transport such as SR-MPLS over IPv4, SR-MPLS over IPv6, SRv6 and SRm6. "Use cases of Application-aware Networking (APN) in Edge Computing", Peng Liu, Zongpeng Du, Shuping Peng, Zhenbin Li, 2021-01-12, 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) fits as the missing puzzle piece to bridge the applications and the network 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. "Use Cases for RATS", chenmeiling, Li Su, 2020-09-10, This document presents two three scenarios from the Internet Service Providers' perspective as an supplement use case of the RATS work group. And make some discussions of access authentication, application authentication and trusted link. "An Architecture for Network Function Interconnect", Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene, 2020-12-27, 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, 2020-09-01, 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, 2020-09-01, 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, 2020-09-01, 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. "Algorithm Related IGP-Adjacency SID Advertisement", Shaofu Peng, Ran Chen, Ketan Talaulikar, 2020-12-07, 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 "The Big Data Approach for Multipoint Alternate Marking method", Mauro Cociglio, Calogero Corbo, Giuseppe Fioccola, Massimo Nilo, Riccardo Sisto, 2020-10-30, This document introduces a new approach for the Alternate Marking method. It is called Big Data Multipoint Alternate Marking method and, starting from the methodology described in RFC 8321 and RFC 8889, it explains how to implement performance measurement analytics on the Network Management System by analysing the raw data of the network nodes. "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network", Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li, 2020-10-12, Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-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 network which consists of a subset of the network topology and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services. I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a set of Segment Routing (SR) based VTNs. This document describes a simplified mechanism to build the SR based VTNs using IS-IS Multi- Topology together with other well-defined IS-IS extensions. "Using Flex-Algo for Segment Routing based VTN", Yongqing Zhu, Jie Dong, Zhibo Hu, 2020-09-11, As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to provide enhanced VPN service to support the 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 network which consists of a subset of network topology and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services. I-D.dong-lsr-sr-enhanced-vpn defines the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based VTNs. This document describes a simplified mechanism to build the SR based VTNs using SR Flex-Algo together with minor extensions to IGP L2 bundle. "The SRT Protocol", Maria Sharabayko, Maxim Sharabayko, Jean Dube, Joonwoong Kim, Jeongseok Kim, 2020-09-09, 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. "DNS Resolving service Discovery Protocol (DRDP)", Daniel Migault, 2020-07-28, This document describes the DNS Resolver Discovery Protocol (DRDP) that enables a DNS client to discover various available local and global resolving service. The discovery is primarily initiated by a DNS client, but a resolving service may also inform the DNS client other resolving services are available and eventually preferred. "Problem Statement of Signal Degrade Indication for SR over MPLS", Fan Yang, Liuyan Han, Junfeng Zhao, 2020-11-02, This document outlines the problem statements and the use cases needed to be taken into account when the signal degrade is detected and indicated in Segment Routing (SR) over MPLS networks. "Security Considerations for Protocol Designers", Dominique Lazanski, 2021-01-07, 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-01. 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, Liang Geng, 2020-11-02, This document introduces a method to decrease the micro-bursts in Layer3 network for low-latency traffic. "BCP72 - A Problem Statement", Mark McFadden, 2021-01-10, 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-01-04, 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-01-05, 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, 2020-12-10, 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. "Enhancing Security and Privacy with In-Network Computing", Ina Fink, Klaus Wehrle, 2020-09-08, With the growing interconnection of devices, cyber-security and data protection are of increasing importance. This is especially the case regarding cyber-physical systems due to their close entanglement with the physical world. Misbehavior and information leakage can lead to financial and physical damage and endanger human lives and well- being. Thus, hard security and privacy requirements are necessary to be met. Furthermore, a thorough investigation of incidents is essential for ultimate protection. In-network computing allows the processing of traffic and data directly in the network and at line- rate. Thus, the in-network computing paradigm presents a promising solution for efficiently providing security and privacy mechanisms as well as event analysis. This document discusses select mechanisms to demonstrate how in-network computing concepts can be applied to counter existing shortcomings of cyber-security and data privacy. "Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk, 2020-11-02, This document specifies the operations performed by a forward-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Proxy operations involve the processing of individual responses from servers, as reply to a single request sent by the client over unicast to the proxy, and then distributed by the proxy over IP multicast to the servers. When receiving the different responses via the proxy, the client is able to distinguish them and their origin servers, by acquiring their addressing information. "A CBOR Tag for Unprotected CWT Claims Sets", Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann, 2020-12-02, CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. "IETF Network Slice Intent", Luis Contreras, Panagiotis Demestichas, Jeff Tantsura, 2020-11-02, Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introduction of new services such as 5G. This document explores the usage of intent technologies for requesting IETF network slices. "CBOR Encoding of X.509 Certificates (CBOR Certificates)", Shahid Raza, Joel Hoglund, Goeran Selander, John Mattsson, Martin Furuhed, 2021-01-19, This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called CBOR Certificates. The CBOR encoding supports a large subset of RFC 5280 and significantly reduces the size of certificates compatible with e.g. RFC 7925, IEEE 802.1AR (DevID), CNSA, and CA/Browser Forum Baseline Requirements. 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 encoding can also be used to encode "natively signed" CBOR certificates, which does not require re-encoding for the signature to be verified. The document also specifies COSE headers as well as a TLS certificate type for CBOR certificates. "Mathematical Mesh 3.0 Part XIII: Mesh Ceremonies", Phillip Hallam-Baker, 2020-07-27, Ceremonies are security protocols that involve human participants as principal actors. Ceremonies for onboarding devices, establishing trust between parties and obtaining multi-factor authenticated responses from users are presented and analyzed with particular application to the Mathematical Mesh. 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 . "Reference Integrity Measurement Extension for Concise Software Identities", Henk Birkholz, Patrick Uiterwijk, David Waltermire, Shwetha Bhandari, Jessica Fitzgerald-McKay, 2021-01-13, This document specifies the CDDL and usage description for Reference Integrity Measurements (RIM) in Remote Attestation Procedures (RATS). The specification is based on Concise Software Identification (CoSWID) and TCG Reference Integrity Manifest Information Model - based on Host Integrity at Runtime and Start-up (HIRS). Extension points defined in CoSWID used to augment CoSWID tags with new attributes that can express the TCG Reference Integrity Manifest extensions. "BGP Well Known Large Community", Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley, 2020-09-09, A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities. "Multipath schedulers", Olivier Bonaventure, Maxime Piraux, Quentin De Coninck, Matthieu Baerts, Christoph Paasch, Markus Amend, 2020-09-09, This document proposes a series of abstract packet schedulers for multipath transport protocols equipped with a congestion controller. "Strong Assertions of IoT Network Access Requirements", Brendan Moran, Hannes Tschofenig, 2020-11-02, 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. "Abstract", Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li, 2020-12-19, 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, 2020-11-15, This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone environment to provide much of the FAA mandated 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. "The MASQUE Protocol", David Schinazi, 2020-09-09, This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection. For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. 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/DavidSchinazi/masque-drafts. "Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)", Thomas Graf, 2020-09-12, This document introduces additional code points in the mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3 and BGP MPLS Segment Routing (SR) extensions to enable Segment Routing label protocol type information in IP Flow Information Export (IPFIX). "Additional Criteria for Nominating Committee Eligibility", Brian Carpenter, Stephen Farrell, 2021-01-07, This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713. "DNS Server Selection: DNS Server Information with Assertion Token", Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair, 2020-08-31, The document defines a mechanism that allows communication of DNS resolver information to DNS clients for use in server selection decisions. In particular, the document defines a mechanism for a DNS server to communicate its filtering policy and privacy statement URL to DNS clients. This information is cryptographically signed to attest its authenticity. Such information is used for the selection of DNS resolvers. Typically, evaluating the DNS privacy statement, filtering policy, and the signatory, DNS clients with minimum human intervention can select the DNS server that best supports the user's desired privacy and filtering policy. This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS- over-HTTPS, 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, 2020-10-29, 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 how TOTP (RFC 6238) can be used as the second factor. "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses", Mario Loffredo, Gavin Brown, 2020-07-31, This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. "DRIP Identity Claims", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2020-11-02, This document describes the Identity Proofs (in the form of Claims, Certificates and Attestations) for use in various Drone Remote ID Protocols (DRIP) and the wider Unmanned Traffic Management (UTM) system. "DRIP Authentication Formats", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2020-12-17, 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. "Real-time text solutions for multi-party sessions", Gunnar Hellstrom, 2020-12-17, 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, 2020-12-28, 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. "BGP-LS Extensions for Shorter SRv6 SID", Liu Yao, Shaofu Peng, 2020-10-15, This document describes the BGP-LS extensions required to support the Shorter SRv6 SIDs(Compressing SRv6 SIDs). "UAS Operator Privacy for RemoteID Messages", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-10-23, 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. "Reliable and Available Wireless Architecture/Framework", Pascal Thubert, Georgios Papadopoulos, Rex Buddenberg, 2020-11-15, Due to uncontrolled interferences, including the self-induced multipath fading, deterministic networking can only be approached on wireless links. The radio conditions may change -way- faster than a centralized routing can adapt and reprogram, in particular when the controller is distant and connectivity is slow and limited. RAW separates the routing time scale at which a complex path is recomputed from the forwarding time scale at which the forwarding decision is taken for an individual packet. RAW operates at the forwarding time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the routing, which will be used for each individual packet to provide a DetNet service while minimizing the waste of resources. "The Vulcain Protocol", Kevin Dunglas, 2020-09-12, This specification defines new HTTP headers (and query parameters) allowing a client to inform the server of the exact data it needs: * "Preload" informs the server that relations of the main requested resource will be necessary. The server can then reduce the number of round-trips by sending the related resources ahead of time using HTTP/2 [RFC7540] Server Push. When using Server Push isn't possible (resources served by a different authority, client or server not supporting HTTP/2...), the server can hint the client to fetch those resources as early as possible by using the "preload" link relation [W3C.CR-preload-20190626] and the "103" status code [RFC8297]. * "Fields" informs the server of the list of fields of the retrieved resources that will be used. In order to improve performance and reduce bandwidth usage, the server can omit the fields not requested. "Secure UAS Network RID and C2 Transport", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2020-12-25, This document provides the mechanisms for secure transport of UAS Network-RemoteID and Command-and-Control messaging. Both HIP and DTLS based methods are described. "QUIC Version Aliasing", Martin Duke, 2020-10-30, The QUIC transport protocol [QUIC-TRANSPORT] 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. "YANG data model for shorter srv6", Ran Chen, 2020-10-14, This document is to define the YANG data model for shorter srv6( Compressing SRv6 ). "Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery Smyslov, 2020-09-09, This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- over-QUIC (DoQ). "BGP Extensions to Support Packet Network Slicing in SR Policy", Liu Yao, Shaofu Peng, 2020-10-15, [I-D.peng-teas-network-slicing] defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This document defines extensions to BGP in order to advertise AII in SR policies. "BGP-LS Extensions for Transport Slice over IPv6 Dataplane", Shaofu Peng, 2020-10-13, [I-D.peng-teas-network-slicing]defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This draft defines extensions to BGP-LS protocol in order to advertise the information of the transport slice over IPv6 dataplane.. "LTP Fragmentation", Fred Templin, 2020-12-14, 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, 2020-10-16, This document describes mechanisms to limit the negative impact of route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] implementations. "ASN Label Switching Protocol (ALSP) Specification", Khaled Omar, 2020-10-21, This document specifies ASN Label Switching Protocol (ALSP). This contribution has been withdrawn. "EVPN Egress Protection", Yubao Wang, Ran Chen, 2020-10-29, A fast reroute framework for egress node protection is specified by [RFC8679] . But it cannot be applied to EVPN directly. This document specifies a mechanism to apply Egress Node Protection to EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI routes, especially for the convergency of BUM packets and the unified signallings for the MPLS SPEs and TPEs. "RPL Storing Root-ACK", Rahul Jadhav, 2020-11-30, This document explains problems with DAO-ACK handling in RPL Storing MOP and provides updates to RFC6550 to solve those problems. "Optimizing ACK mechanism for QUIC", Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang, 2020-11-16, 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. "The Problem Statement for Precise Transport Networking", Quan Xiong, Peng Liu, 2020-10-31, As described in [I-D.xiong-rtgwg-precise-tn-requirements], the deterministic networks not only need to offer the Service Level Agreements (SLA) guarantees such as low latency and jitter, low packet loss and high reliability, but also need to support the precise services such as flexible resource allocation and service isolation so as to the Precise Transport Networking. However, under the existing IP network architecture with statistical multiplexing characteristics, the existing deterministic technologies are facing long-distance transmission, queue scheduling, dynamic flows and per- flow state maintenance and other controversial issues especially in Wide Area Network (WAN) applications. This document analyses the problems in existing deterministic technologies to provide precise services in various industries such as 5G networks. "The Requirements for Precise Transport Networking", Quan Xiong, Peng Liu, 2020-10-31, The future networks not only need to offer the Service Level Agreements (SLA) guarantees such as low lantency and jitter, low packet loss and high reliability, but also need to support the precise services such as flexible resource allocation and service isolation. This document proposes a set of performance requirements and precise properties for Precise Transport Networking in various industries such as 5G networks. "Describing QUIC's Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2020-11-02, 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. "IPv4 NLRI with IPv6 Next Hop Use Cases", Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Lili Wang, 2020-11-18, As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role in the transition of the core from IPv4 to IPv6 being able to continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 customers. This document describes the critical use case and OPEX savings of being able to leverage the MP-BGP capability exchange usage as a pure transport allowing both IPv4 and IPv6 to be carried over the same BGP TCP session. By doing so, allows for the elimination of Dual Stacking on the PE-CE connections making the peering IPv6-ONLY to now carry both IPv4 and IPv6 Network Layer Reachability Information (NLRI). This document now provides a solution for IXPs (Internet Exchange points) that are facing IPv4 address depletion at these peering points to use BGP-MP capability exchange defined in [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI in an IPv6 next hop using the [RFC5565] softwire mesh framework. "In-band Network-Wide Telemetry", Tian Pan, Minglan Gao, Enge Song, Zizheng Bian, Xingchen Lin, 2020-10-25, This document describes INT-path, a cost-effective network-wide telemetry framework based on INT (In-band Network Telemetry), by decoupling the network monitoring system into a routing mechanism and a routing path generation policy. INT-path embeds SR (Source Routing) into INT probes to allow specifying the route that the probe packet takes through the network. Above this probing path control mechanism, an Euler trail-based path planning policy is developed to generate non-overlapped INT paths that cover the entire network with a minimum path number, reducing the overall telemetry overhead. INT- path is very suitable for deployment in data center networks thanks to their symmetric topologies. "A Bootstrapping Procedure to Discover and Authenticate DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BYOD Devices", Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair, 2020-07-26, This document specifies mechanisms to bootstrap endpoints (e.g., hosts, IoT devices) to discover and authenticate DNS-over-TLS and DNS-over-HTTPS servers provided by a local network for IoT/BYOD devices in Enterprise networks. "TCP Encapsulation of IKE and IPsec Packets", Valery Smyslov, Tommy Pauly, 2020-10-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. "PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks", Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar, 2020-11-19, 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, 2021-01-04, 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 maps to a desired SLA. It specifies BGP protocol procedures that enable dissimination 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 dissiminates "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, 2020-11-15, 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- 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. "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2020-11-18, 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, 2020-12-16, When PBB EVPN [RFC7623] is used in Segment Routing networks, it is complicated to make use of the SID list to carry a function that is aiming for C-MACs. In [I-D.ietf-spring-srv6-network-programming], 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 activated for End.DX2 function. On the basis of such End.DX2 function, SRv6 EVPN can 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, 2020-11-15, 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, 2020-11-14, This informational draft documents the lispers.net LISP NAT-Traversal implementation. "Defined Resource Operator (drop) The 'drop' URI Scheme", Tim McSweeney, 2020-08-30, This document describes the 'drop' Uniform Resource Identifier (URI) scheme. "Compressed SRv6 Segment List Encoding in SRH", Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Dezhong Cai, Daniel Voyer, Francois Clad, Shay Zadok, Jim Guichard, Liu Aihua, 2020-11-17, This document defines a compressed SRv6 Segment List Encoding in the 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. "Secure Frame (SFrame)", Emad Omara, Justin Uberti, Alexandre Gouaillard, Sergio Murillo, 2020-11-16, 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. "A Framework For Decentralized Bearer Token Issuance in HTTP", Michael Thornburgh, 2020-08-26, This memo describes a protocol framework for HTTP clients to obtain bearer tokens for accessing restricted resources, where in some applications the client may not have prior knowledge of, or a direct relationship with, the resource server's authorization infrastructure (such as in decentralized identity systems). Semi-concrete applications of the framework using proof-of-possession and TLS client certificate mechanisms are also described. "Internet Protocol Encapsulation of AX.25 Frames", Iain Learmonth, 2020-11-19, 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, 2020-10-18, This document contains the GNU Name System (GNS) technical specification. "Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4", Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong, 2020-11-23, This draft defines a new Outbound Route Filter (ORF) type, called the Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the routers do not exchange VPN routing information directly (e.g. routers in single-domain connect via Route Reflector, or routers in Option B/Option AB/Option C cross-domain scenario). "JOSE Authentication", Dick Hardt, 2020-08-15, TBD "The Grant Negotiation and Authorization Protocol - Advanced Features", Dick Hardt, 2020-08-15, TBD "TCP-AO Test Vectors", Joseph Touch, Juhamatti Kuusisaari, 2020-12-23, This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: one based on SHA-1 and the other on AES-128. The vectors also validate both whole TCP segments as well as segments whose options are excluded for NAT traversal. "Network Tokens", Yiannis Yiakoumis, Nick McKeown, Frode Sorensen, 2020-12-22, Network tokens is a method for endpoints to explicitly and securely coordinate with networks about how their traffic is treated. They are inserted by endpoints in existing protocols, interpreted by trusted networks, and may be signed or encrypted to meet security and privacy requirements. Network tokens provide a means for network operators to expose datapath services (such as a zero-rating service, a user-driven QoS service, or a firewall whitelist), and for end users and application providers to access such services. Network tokens are inspired and derived by existing security tokens (like JWT and CWT), and borrow several of their core ideas along with security and privacy properties. "HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Hongqiang Liu, Rong Pan, Jeongkeun Lee, Changhoon Kim, Barak Gafni, Yuval Shpigelman, 2020-09-11, 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 inband telemetry information during congestion and overreaction to inband telemetry information, HPCC++ can quickly converge to utilize free 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. "Security Needs for the NFSv4 Protocols", David Noveck, Chuck Lever, 2021-01-21, This document discusses the inadequate approach to security within the family of NFSv4 protocol specifications and proposes steps to correct the situation. Because the security architecture is similar for all NFSv4 minor versions, we recommend a single new standards- track document to encapsulate NFSv4 security fundamentals, and propose the introduction of several additional security-related documents. "Use cases of Application-aware Networking (APN) in Game Acceleration", Shuai Zhang, Chang Cao, Shuping Peng, Zhenbin Li, 2020-12-14, 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. "Attestation Event Stream Subscription", Henk Birkholz, Eric Voit, Wei Pan, 2020-10-06, This document defines how to subscribe to an Event Stream of attestation related Evidence on TPM-based network devices. "Identity Module for TLS Version 1.3", Pascal Urien, 2021-01-16, 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 Contexts", Brian Sipos, 2020-12-22, 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 is also defined for BPSec interoperation. "Trusted Path Routing", Eric Voit, 2020-10-02, 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. 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. "Greasing the QUIC Bit", Martin Thomson, 2020-11-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. "TLS Application-Layer Protocol Settings Extension", David Benjamin, Victor Vasiliev, 2020-09-21, This document describes a Transport Layer Security (TLS) extension for negotiating application-layer protocol settings (ALPS) within the TLS handshake. Any application-layer protocol operating over TLS can use this mechanism to indicate its settings to the peer in parallel with the TLS handshake completion. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2020-11-16, This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. "SCHC over PPP", Pascal Thubert, 2020-09-22, 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. "BGP UPDATE for SDWAN Edge Discovery", Linda Dunbar, Susan Hares, Robert Raszuk, Kausik Majumdar, 2020-11-18, The document describes encoding of BGP UPDATE messages for the SDWAN edge node discovery. In the context of this document, BGP Route Reflectors (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. "QUIC-based UDP Transport for Secure Shell (SSH)", denis bider, 2020-12-02, The Secure Shell protocol (SSH) [RFC4251] is widely used for purposes including secure remote administration, file transfer using SFTP and SCP, and encrypted tunneling of TCP connections. Because it is based on TCP, SSH suffers similar problems as motivate the HTTP protocol to transition to UDP-based QUIC [QUIC]. These include: unauthenticated network intermediaries can trivially disconnect SSH sessions; SSH connections are lost when mobile clients change IP addresses; performance limitations in OS-based TCP stacks; many round-trips to establish a connection; duplicate flow control on the level of the connection as well as channels. This memo specifies SSH key exchange over UDP and leverages QUIC to provide a UDP-based transport. "Performance Measurement on LAG", Zhenqiang Li, Mach Chen, Greg Mirsky, 2020-11-02, This document defines extensions to One-way Active Measurement Protocol (OWAMP), Two-way Active Measurement Protocol (TWAMP), and Simple Two-Way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). With the measured metrics of each member links of a LAG, it enables operators to enforce performance metric based traffic steering policy among the member links. "Using TLS Application-Layer Protocol Settings (ALPS) in HTTP", Victor Vasiliev, 2021-01-21, This document describes the use of TLS Application-Level Protocol Settings (ALPS) in HTTP/2 and HTTP/3. Additionally, it defines a set of additional HTTP SETTINGS parameters that would normally be impractical without ALPS. "A Proposed Model for RFC Editing and Publication", Martin Thomson, 2020-08-09, The finishing process for a document that is approved for publication as an RFC currently involves a somewhat detailed and lengthy process. The system that executes that process involves a number of different actors, each bringing competency with different aspects of the overall process. Ensuring that this process functions smoothly is critical to the mission of the organizations that publish documents in the RFC series. This document proposes a framework for that system that aims to provide clear delineations of accountability and responsibility for each of the actors in this system. "Greasing HTTP", Mark Nottingham, 2020-10-07, Like many network protocols, HTTP is vulnerable to ossification of its extensibility points. This draft explains why HTTP ossification is a problem and establishes guidelines for exercising those extensions by 'greasing' the protocol to combat it. "Distributed Ledger Time-Stamp", Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano, 2021-01-07, 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-01-14, When a DNS server filters a query, the response to such query conveys no detailed explanation that explains 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. "Multipath sequence maintenance", Markus Amend, Dirk Hugo, 2020-11-02, This document discusses the issue of packet re-ordering which occurs as a specific problem in multi-path connections without reliable transport protocols such as TCP. The topic is relevant for devices connected via multiple accesses technologies towards the network as is foreseen e.g. within Access Traffic Selection, Switching, and Splitting (ATSSS) service of 3rd Generation Partnership Project (3GPP) enabling fixed mobile converged (FMC) scenario. "Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure", Renan Krishna, Akbar Rahman, 2020-10-30, 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. "Transport Considerations for IP and UDP Proxying in MASQUE", Magnus Westerlund, Marcus Ihlar, Zaheduzzaman Sarker, Mirja Kuehlewind, 2021-01-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. "pretty Easy privacy (pEp): Email Formats and Protocols", Hernani Marques, 2020-11-02, The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption a viability for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). "Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM Data Collection", Yali Wang, Tianran Zhou, Hongwei Yang, Chang Liu, 2020-11-14, This document defines optional TLVs which are carried in Simple Two- way Active Measurement Protocol (STAMP) test packets to enhance the STAMP base functions. Such extensions to STAMP enable OAM data measurement and collection at every node and link along a STAMP test packet's delivery path without maintaining a state for each configured STAMP-Test session at every devices. "Concepts of Digital Twin Network", Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, 2020-11-16, Digital twin technology is becoming a hot technology in industry 4.0. The application of digital twin technology in network field helps to realize efficient and intelligent management and network innovation. This document presents an overview of the concepts of Digital Twin Network (DTN), provides the definition and DTN, and then describes the benefits and key challenges of DTN. "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, 2020-11-02, 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, 2020-11-02, This document specifies the mechanisms to signal Virtual Private Wire Services (VPWS) carrying bit-stream signals over Packet Switched Networks (PSN). "SRv6 Point-to-Multipoint Path", Huaimo Chen, Mike McBride, Yanhe Fan, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu, 2020-09-28, 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. "Generic Route Constraint Distribution Mechanism for BGP", Zhaohui Zhang, Jeffrey Haas, 2021-01-11, 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). "MPLS-based Service Function Path(SFP) Consistency Verification", Liu Yao, Greg Mirsky, 2020-10-25, This document proposes a method to verify the correlation between Service Function Chaining control and/or management plane view of the specified Service Function Path and the state of its data. It works for both SR service programming and MPLS-based NSH SFC. This document defines the signaling of the Generic Associated Channel (G-ACh) over a Service Function Path (SFP) with an MPLS forwarding plane using the basic unit defined in RFC 8595. The document also describes the processing of the G-ACh by the elements of the SFP. "Differential Computing Resource Reservation", Peng Liu, Huijuan Yao, Liang Geng, 2020-10-31, Computing in the network may require the embedded computing capability in the network device, such as gateway, switch, etc, and there might be so much distributed computing task in the network. Some new applications like AR/VR, motion control put forward higher demand of network than before, and AI is also considered to be used in the app and network. In order to satisfy the demands, it needs to guarantee both the bandwidth resource and the computing resource which is linked by the network. "Author Header Field", Dave Crocker, 2020-07-27, Internet mail defines the From: field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message. The Sender: field is optional, if it has the same information as the From: field. That is, when the Sender: field is absent, the From: field has conflated semantics, as both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments the current use of the From: field, by specifying the Author: field, which identifies the original author of the message and is not subject to modification by Mediators. "Principles for the Involvement of Intermediaries in Internet Protocols", Martin Thomson, 2021-01-03, 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 Segment Routing", Shraddha Hegde, Chris Bowers, Xiaohu Xu, Arkadiy Gulko, Alex Bogdanov, Jim Uttaro, Luay Jalil, Mazen Khaddam, Andrew Alston, 2021-01-07, In order to operate networks with large numbers of devices, network operators organize networks into multiple smaller network domains. Each network domain typically runs an IGP which has complete visibility within its own domain, but limited visibility outside of its domain. Seamless Segment Routing (Seamless SR) provides flexible, scalable and reliable end-to-end connectivity for services across independent network domains. Seamless SR accommodates domains using SR, LDP, and RSVP for MPLS label distribution as well as domains running IP without MPLS (IP-Fabric).It also provides seamless connectivity across domains having different IPv6 technologies such as SRv6 and SRm6. "TCP ACK Rate Request Option", Carles Gomez, Jon Crowcroft, 2020-11-01, TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to indicate the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. "Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM) Data", Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro, 2021-01-08, 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, Yunan Gu, 2020-12-25, BGP Flow Specification (FlowSpec) [I-D.ietf-idr-rfc5575bis] 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. "Accurate Data Scheduling by Server in MPTCP", Jiao Kang, liangqiandeng, 2020-11-02, This document defines a new mechanism that enables MPTCP server to send request to MPTCP client for data scheduling between specified subflows during a MPTCP session. "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-01-21, The data model defined in RFC8345 introduces vertical layering relationships between networks that can be augmented to cover network/service topologies. This document defines a YANG model for both Network Performance Monitoring 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. This document does not define metrics for network performance or mechanisms for measuring network performance. 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 8299, RFC 8345, and RFC 8532. "Forwarding Layer Use Cases", Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm, 2021-01-04, 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. "IGP Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement", Yali Wang, Tianran Zhou, Fengwei Qin, Huanan Chen, Ran Pang, 2020-07-28, This document extends Node and Link Attribute TLVs to Interior Gateway Protocols (IGP) to advertise supported In-situ Flow Information Telemetry (IFIT) capabilities at node and/or link granularity. An ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In addition, such advertisements would be useful for ingress routers to gather each router's IFIT capability for achieving the computation of Traffic Engineering (TE) paths or loose TE paths that be able to fulfill the visibility of on-path OAM data. "Combining EDHOC and OSCORE", Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander, 2020-11-02, This document defines possible optimization approaches 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 complete an OSCORE transaction using that context. "SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2020-11-20, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS. "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Dispatch Type for SCHC", Carles Gomez, 2020-09-21, A new framework called Static Context Header Compression (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. This document defines a 6LoWPAN Dispatch Type to signal when a packet header has been compressed by using SCHC header compression. "IP Traffic Flow Security YANG Module", Don Fedyk, Christian Hopps, 2020-11-15, This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. "An Investigation into Randomized Response Mechanisms in RTT Measurements for QUIC", Amelia Andersdotter, Shivan Sahib, 2020-08-14, The latency spin bit is an optional feature included in the QUIC transport protocol, as standardized by the Internet Engineering Task Force (IETF). It enables passive, on-path observations for estimation of latency. This document presents the results of an inquiry into the potential of using randomized response mechanisms (RRM) to reduce privacy loss in latency measurements. It concludes that RRM could be used to introduce choice for clients in preserving privacy in latency measurements. But the trade-offs, especially since the latency spin bit is already optional, do not favour RRM. "Trustworthiness Vectors for the Software Updates of Internet of Things (SUIT) Workflow Model", Henk Birkholz, Brendan Moran, 2021-01-13, 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. "YANG Data Model for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro, Guangying Zheng, 2021-01-21, This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. "CoAP Transport for CMPV2", Mohit Sahni, Saurabh Tripathi, 2020-10-05, This document specifies the use of Constrained Application Protocol (CoAP) as a transport medium for the Certificate Management Protocol Version 2 (CMPv2) and Lightweight CMP Profile [Lightweight-CMP-Profile] CMPv2 defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP like client-server protocol used by various constrained devices in IoT space. "Client Hint Reliability", David Benjamin, 2020-11-30, 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. "RFC 7258 additions due to evolving Internet thread model", Jari Arkko, Stephen Farrell, 2020-08-20, 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. RFC 7258 is the IETF guidance on taking into account pervasive monitoring threats in Internet technology development work. This memo suggests additions to RFC 7258 to cater for the evolving threats. For instance, it may be necessary to also worry about information collected by a legitimate protocol participant being misused for pervasive monitoring purposes. "BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities", Yali Wang, Shunwan Zhuang, Yunan Gu, 2020-10-27, 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-01-14, 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. "Secure Negotiation of Incompatible Protocols in TLS", Martin Thomson, 2021-01-03, An extension is defined for TLS that allows a client and server to detect an attempt to force the use of less-preferred application protocol even where protocol options are incompatible. This supplements application-layer protocol negotiation, which allows choices between compatible protocols to be authenticated. "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", Stephen Kent, Di Ma, 2020-07-25, This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. "Autonomic Control Plane challenges for Layer-Two Switched Networks", Michael Richardson, Jie Yang, 2020-07-26, This document details the challenges with building an Autonomic Control Plane on Campus/Enterprise networks which are built out of layer-two (Ethernet) switched technologies. This document does not propose a specific solution as yet, but details a number of possibilities, and what it would take to standardize each possibility. "DNS DOTS considerations", Haikuo Zhang, Peng Zuo, Yungang Sun, Meng Yuan, 2020-07-26, DDoS Open Threat Signaling(DOTS) described in [RFC8612] is a standardized method to coordinate a real-time response among involved operators. This document focus on the considerations regard to the use of DOTS to mitigate DNS-Related DDoS attacks. "Compact UUIDs for Constrained Grammars", Dorian Taylor, 2021-01-17, 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-01-18, 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, Daniel Voyer, Rishabh Parekh, Zhaohui Zhang, 2020-07-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). "Mathematical Mesh 3.0 Part XII: Mesh Presence", Phillip Hallam-Baker, 2020-07-27, 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 . "Mathematical Mesh 3.0 Part XI: Cryptographic Services", Phillip Hallam-Baker, 2020-07-27, https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . "IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions", Venkata Munukutla, Shivam Vaid, Aditya Mahale, Devang Patel, 2020-07-27, 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. "DNS Resolver Discovery Protocol (DRDP)", Daniel Migault, 2020-07-28, The DNS Resolving service Discovery Protocol (DRDP) enables to discover resolving services available and eventually upgrade to an encrypted resolving service. DRDP requires a resolving domain or a pointer to a list of resolving domains. Currently ISP or CPEs do not advertise resolving domain or pointers to resolving domains which does not make possible for a DNS client to discover potential resolving services - such as encrypted DNS for example - made available by the ISP. Instead, ISPs or CPE advertise via DHCP the IP address of the host with a IA Address Option [RFC3315] and the IP addresses of the resolver provided by the ISP with Recursive Name Server option [RFC3646]. This document describes a procedure for a DNS client to derive resolving domains from the legacy configuration of the host. This is expected to ease the deployment of encrypted DNS from ISP as it will enable OS, applications to discover resolving service put in place by the ISP even though the CPE has not been upgraded. "SVG Tiny Portable/Secure", Alex Brotman, J. Adams, 2020-07-29, 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. "Operational Guidance for Deployment of L4S in the Internet", Greg White, 2020-11-02, This draft is intended to provide guidance to operators of end- systems, operators of networks, and researchers in order to ensure successful deployment of L4S in the Internet. It includes mechanisms that are intended to promote reasonable fairness between L4S and Classic flows sharing a single-queue [RFC3168] bottleneck link. This draft identifies opportunites to prevent and/or detect and resolve fairness problems in such networks. "Service Binding Mapping for DNS Servers", Benjamin Schwartz, 2020-08-10, 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. "AAA-based assisted EDHOC Authentication", Eduardo Sanchez, Dan Garcia-Carillo, Rafael Marin-Lopez, 2020-08-05, This document describes a proposal to place EDHOC server in an external Authentication, Authorization and Accounting (AAA) server. The purpose is to centralize the EDHOC authentication in AAA infrastructure. "EAP method based on EDHOC Authentication", Eduardo Sanchez, Dan Garcia-Carrillo, Rafael Marin-Lopez, 2020-11-02, This document describes a proposal of an EAP method based on the EDHOC authentication protocol. "FROST: Flexible Round-Optimized Schnorr Threshold Signatures", Chelsea Komlo, Ian Goldberg, 2020-08-07, Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers each holding a share of a common private key. Consequently, generating signatures in a threshold setting imposes overhead due to network rounds among signers, proving costly when secret shares are stored on network- limited devices or when coordination occurs over unreliable networks. This draft describes FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme that reduces network overhead during signing operations while employing a novel technique to protect against forgery attacks applicable to similar schemes in the literature. FROST improves upon the state of the art in Schnorr threshold signature protocols, as it can safely perform signing operations in a single round without limiting concurrency of signing operations, yet allows for true threshold signing, as only a threshold number of participants are required for signing operations. FROST can be used as either a two-round protocol where signers send and receive two messages in total, or optimized to a single-round signing protocol with a pre-processing stage. FROST achieves its efficiency improvements in part by allowing the protocol to abort in the presence of a misbehaving participant (who is then identified and excluded from future operations)--a reasonable model for practical deployment scenarios. "Fault Management Mechanism in MPTCP Session", Jiao Kang, liangqiandeng, 2020-08-09, This document presents a mechanism for fault management during a MPTCP session. It is used to convey subflow failure information from client to server by other subflow running normally. It includes: 1) a new Fault Announce Option for describing subflow failure, 2) implementation and interoperability of this option during a MPTCP session when one subflow suffers a failure. In fact, the server is able to determine network problems accurately based on these fault information reported from multiple clients for their connections. "QUIC Disable Encryption", Nick Banks, 2020-08-11, The disable_1rtt_encryption transport parameter can be used to negotiate the disablement of encryption on 1-RTT packets, allowing for reduced CPU load and improved performance. This extension is only meant to be used in environments where both endpoints completely trust the path between themselves; not, for instance, on the open internet. "The Transport Layer Security (TLS) Protocol Version 1.3", Eric Rescorla, 2020-08-11, This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. "Finding the Authoritative Registration Data (RDAP) Service", Marc Blanchet, 2020-08-11, This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin, Michael Richardson, Toerless Eckert, Michael Behringer, Kent Watsen, 2020-08-11, This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. "Requirement for the transparency of RPKI", Yaping Liu, Shuo Zhang, Qingyuan Li, Sufang Peng, 2020-08-13, This document provides the transparency requirement of a Certificate Authority (CA) or Repository resource management agency in Resource Public Key Infrastructure (RPKI), which references multiple content in some RFCs related to RPKI. It is easier for implementers to be aware of these requirements "Testing, Please Ignore", Colin Perkins, 2020-08-13, This is a test. "Protocol for Evaluating Reinforcement Learning Environments in Real Time", Ruben Montero, 2020-08-13, This document defines a simple UDP protocol for communicating a server simulating a reinforcement learning environment and a client observing it and responding with actions. Reinforcement learning problems are usually defined within the scope of a Markov Decission Process (MDP) where an agent sends an action belonging to an action space to an environment. The environment acts as a black box returning an observation and a reward for the agent, whose goal is to maximize the total obtained rewards. Although the problem statement is easy to understand, there are no conventions on how to communicate a reinforcement learning simulation with a client agent, either in a local network or over the Internet. Additionally, giving an answer to this can be especially useful when it comes to multiagent support and analysis. The protocol PERLERT defined in this document assumes that server and client have shared certain information beforehand via another way of communication like a web page served using HTTP protocol. For example, the client must know a port number and an instance number before proceeding to participate in a simulation run on a server. Also, although it is often desired to know the full feedback from the environment, PERLERT focuses on real-time interaction where human agents can interact with AI agents even if that means that information can be lost due to network packet loss. "Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)", Nicholas Gajcowski, Michael Jenkins, 2020-08-14, 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. "Rechartering the IETF Discussion List", Mark Nottingham, 2020-08-16, This document updates RFC3005, the charter of the IETF discussion list. "SRv6 SID Allocation Requirements", Ran Chen, Shaofu Peng, 2020-08-17, This document describes a SRv6 SID allocation method. "Open Participation Principle regarding Remote Registration Fee", Mirja Kuehlewind, Jonathan Reed, Rich Salz, 2021-01-18, This document proposes a principle for open participation that extends the open process principle as defined in RFC3935 by stating that there must always be a free option for online participation to IETF meetings over the Internet. "Least-Common Scope Communications", Dusan Mudric, Alexandre Petrescu, 2020-11-14, This draft formulates a security problem statement. The problem arises when a Host uses its Global Unicast Address (GUA) to communicate with another Host situated on the same link. To address this problem, we suggest to select and use addresses of a least scope that are common. "A Taxonomy of operational security of manufacturer installed keys and anchors", Michael Richardson, Jie Yang, 2020-08-27, This document provides a toxonomy of methods by manufacturers of silicon and devices 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 "Distributed KV Store based Routing protocol for SR over UDP(SRoU)", Kevin Fang, Yinghao Li, Feng Cai, Xing Jiang, 2020-08-20, This document defines the Distributed KV store based routing protocol for Segment Routing over UDP. "Alternative Proposed Model for RFC Editing and Publication", Brian Carpenter, 2020-08-20, The finishing process for a document that is approved for publication as an RFC currently involves a somewhat detailed and lengthy process. The system that executes that process involves a number of different actors, each bringing competency with different aspects of the overall process. Ensuring that this process functions smoothly is critical to the mission of the organizations that publish documents in the RFC series. This document proposes a framework for that system that aims to provide clear delineations of accountability and responsibility for each of the actors in this system. It would require significant updates to RFC 8728 and RFC 8729, and minor updates to RFC 2850 and RFC 7841. Discussion of this document takes place on the RFC Editor Futures mailing list (rfced-future@iab.org). "An Editorial Board-based Management Structure for the RFC Series", Michael StJohns, 2020-08-24, This document describes a revised model for the management, evolution and improvement of the RFC Series led by an RFC Series Editor (RSE) assisted by an RFC Series Editorial Board (RSEB). The model removes the IAB and its appointed RFC Series Oversight Committee (RSOC) from direct control of the RFC Series and the RFC Series Editor, replacing them on the publication evolution side with the RSEB, and on the financial and personnel management side with the IETF Administration Limited Liability Company or its board as appropriate (LLC). "Effective Terminology in IETF drafts", Bron Gondwana, 2020-08-25, The IETF and the RFC series are trusted names, for producing high quality technical documents that make the Internet work better. While the success of our documents is variable, many of them are widely used over a long time period. As norms in the outside world change, our documents need to remain relevant and accessible to future generations of those working on the internet, everywhere in the world. This longevity of our documents, and the impossibility of predicting the future, implies that we should be conservative in the language that we send. Effective language expresses our intent with clarity, and without distraction. This document describes a glossary for increasing awareness of terms which are going to be clear and effective without turning readers away, to enable our mission of making the Internet work better. "Avoiding Exclusionary Language in RFCs", Keith Moore, 2020-08-26, It has been asserted that some language in IETF documents is "exclusionary" - that it offends some readers or groups of people, and/or discourages participation in IETF by doing so. While there is some debate about exactly which language is exclusionary, at least some cited examples of such language can credibly have such effects. It is believed that most instances of such language are accidental, and that most document authors and editors wish to avoid use of language that may be offensive. This memo therefore attempts to establish procedures that warn document authors and editors about language that may credibly having such effects, and thereby, to reduce both accidental and deliberate use of such language. At the same time, it is recognized that in some cases there an be strong and conflicting opinions about whether or not particular language is desirable or appropriate. IETF's primary function is providing technical direction for the benefit of the Internet community, rather than social engineering. If a document can be blocked or substantially delayed over disputes about the proprietary of language in that document, this can be disruptive to IETF's primary function. This memo therefore makes recommendations to prevent such disputes from blocking progress on technical documents. "Supporting Redirection for DNS Queries over HTTPS (DoH)", Mohamed Boucadair, Neil Cook, Tirumaleswar Reddy.K, Dan Wing, 2020-08-27, This document clarifies whether DNS-over-HTTPS (DoH) redirection is allowed, describes potential issues with redirection in DoH, and proposes how DoH redirection might be performed. "Hypertext Transfer Protocol Version 2 (HTTP/2)", Martin Thomson, 2020-08-28, 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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. "Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT", Huanan Chen, Hang Yuan, Tianran Zhou, Weidong Li, Giuseppe Fioccola, Yali Wang, 2020-09-22, 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. "5G Wireline Transport over PPP", Venkatesh Padebettu, 2020-08-30, To support connecting 5G residential gateways(5G-RG) to 5G Core (5GC) over wireline access, the control packets and data packets of the 5G- RG should be transported over the wireline access network (W-AN) to Access Gateway Function(W-AGF). The Point-to-Point Protocol (PPP) [RFC1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the 5G Wireline Control Protocol(5WCP) for establishing and configuring the 5G Wireline Data protocol(5W Data) over PPP for Wireline Access for 5G Networks. The method inherits multiplexing of traffic for multiple 5G-RGs per VLAN from PPPoE [RFC2516] and defines multiplexing multiple PDU Sessions per 5G-RG. "Finding and Using Geofeed Data", Massimo Candela, Randy Bush, Warren Kumari, Russ Housley, 2020-10-12, This document describes how to find and authenticate geofeed data. "Requirements for Adaptive DNS Discovery", Chris Box, Tommy Pauly, Christopher Wood, Tirumaleswar Reddy.K, Daniel Migault, 2020-11-02, Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS resolvers. This document describes one common use case, that of discovering the encrypted DNS resolver that corresponds to the Do53 resolver offered by a network. It lists requirements that any proposed discovery mechanisms should address. 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-add/draft-add-requirements. "Usage scenarios of Application-aware Networking (APN) for SD-WAN", Feng Yang, Weiqiang Cheng, Shuping Peng, Zhenbin Li, 2020-09-06, This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a particular application, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability. "BGP Extensions for Services in SRv6 and MPLS Coexisting Network", Liu Yao, Bing Song, 2021-01-07, This document proposes a method to achieve VPN/EVPN in a network where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP. "The "id-" prefix for Digest Algorithms", Roberto Polli, 2020-12-18, This document defines the "id-" prefix for digest-algorithms used in the Digest HTTP field. This prefix explicits that the value of the digest-algorithm is independent from Content-Encoding. "WebRTC-HTTP ingestion protocol (WHIP)", Sergio Murillo, Alexandre Gouaillard, 2020-09-09, While WebRTC has been very sucessfull in a wide range of scenarios, its adption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay. The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditionnal streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g. Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server- side media processing. This document proposes a simple HTTP based protocol that will allow WebRTC endpoings to ingest content into streaming servics and/or CDNs to fill this gap and facilitate deployment. "Reporting Information from DNS Authoritative Servers", Paul Hoffman, Puneet Sood, 2020-09-09, This document defines a new DNS RRtype, AUTHINFO, that is used by authoritative servers to publish information about themselves. This information can be useful because a recursive resolver can determine an authoritative server's capabilities, such as whether an authoritative server supports the EDNS(0) client subnet extension. "Recursive to Authoritative DNS with Opportunistic Encryption", Paul Hoffman, 2021-01-13, This document describes a use case and a method for a DNS recursive resolver to use opportunistic encryption (that is, encryption with optional authentication) when communicating with authoritative servers. The motivating use case for this method is that more encryption on the Internet is better, and opportunistic encryption is better than no encryption at all. The method here is optional for both the recursive resolver and the authoritative server. Nothing in this method prevents use cases and methods that can use, or require, authenticated encryption. "OSPF Transport Instance Extensions", Acee Lindem, Yingzhen Qu, Abhay Roy, Sina Mirtorabi, 2020-11-02, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is 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. "Discovery Mechanisms for QUIC-based Proxy Services", Mirja Kuehlewind, Zaheduzzaman Sarker, Magnus Westerlund, 2020-09-11, Often an intermediate instance (such as a proxy server) is used to connect to a web server or a communicating peer if a direct end-to- end IP connectivity is not possible or the proxy can provide a support service like, e.g., address anonymisation. To use a non- transparent proxy a client explicitly connects to it and requests forwarding to the final target server. The MASQUE Connect-UDP Proxy service is an example of such a proxy service. The client either knows the proxy address as preconfigured in the application or can dynamically learn about available proxy services. This document describes different discovery mechanisms for non-transparent proxies that are either located in the local network, e.g. home or enterprise network, in the access network, or somewhere else on the Internet usually close to the target server or even in the same network as the target server. This document assumes that the non-transparent proxy server is connected via QUIC and discusses potential discovery mechanisms for such a QUIC-based, non-transparent proxy. "Open Letter to the 2020-21 IETF Nominating Committee", Brian Carpenter, 2020-09-11, This is a personal open letter to the IETF Nominating Committee for 2020-21. "Secure Element for TLS Version 1.3", Pascal Urien, 2020-09-25, 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(Bob) Wang, Zheng Zhang, 2020-09-15, 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 intended 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 [RFC7432] to support this scenario. "IETF Trust Proposed Policy on Rights in IANA Parameter Registry Data", Joel Halpern, Glenn Deen, 2020-09-16, The document is to inform the IETF community of a proposed clarification to the Public Domain status of the IANA Protocol Registries by the IETF Trust.. This document has been developed to explain the proposal and to solicit community discussion and feedback on this proposal. "Problem Statements for MAC Address Randomization", Yiu Lee, Jason Livingood, Jason Weil, 2020-09-22, MAC Addresses are Link Layer addresses used in IEEE Ethernet, WiFi, and other link layer protocols. A MAC Address is a fixed locally unique address assigned by the Network Interface Card (NIC) manufacturer, though they may be modified by an operating system, and they enable a device to connect to a network. Due to the static nature of a MAC Address, it raises some privacy concerns that have led to randomization of MAC Addresses by operating systems. This draft documents the impacts of MAC Address randomization to existing use cases of network and application services and proposes few next steps IETF may consider working on. "Identifier Negotiation for the OSCORE Profile of ACE", Francesca Palombini, 2020-09-21, This document defines a mechanism to negotiate OSCORE security material identifiers for the OSCORE profile of ACE. "OSCORE Profile of ACE v2", Francesca Palombini, 2020-09-21, 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. Additionally, this profile provides OSCORE identifiers negotiation between Client and Resource Server. "Mathematical Mesh 3.0 Part XIV: Mesh Name Service", Phillip Hallam-Baker, 2020-09-21, A naming service for the Mathematical Mesh 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 . "Soure Address Validation: Gap Analysis", Dan Li, Jianping Wu, Yunan Gu, Lancheng Qin, Tao Lin, 2021-01-10, 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. "ND improvement to prevent Man-in-the-middle attack", Eduard, XiPeng Xiao, 2020-09-24, Privacy protection is the bigger and bigger concern of many governments and public in general. ND has a few open man-in-the- middle attack vectors. MITM is considered among the most dangerous attack types because of information leakage. This document proposes minimal modifications for ND to protect IPv6 nodes against still open MITM attacks. It could be implemented gradually on any nodes, with the biggest benefit from support on routers. "Parent-side authoritative DNS records for enhanced delegation", Peter van Dijk, Petr Spacek, 2020-09-24, A DNS RRtype numeric range that behaves like DS is reserved. This means: being authoritative on the parent side of a delegation; being signed by the parent; being provided along with delegations by the parent. If this document had become an RFC five years ago, deploying new types (along the lines of NS2/NS2T, DSPKI or various other imagined things like DNS ('signed delegation NS')) would be easier to deploy and experiment with today. "The VERBATIM Digest Algorithm for DS records", Peter van Dijk, 2020-09-25, The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. "Email Author Header Field", Dave Crocker, 2021-01-17, Internet mail defines the From: field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message, on the author's behalf. The Sender: field is optional, if it has the same information as the From: field. That is, when the Sender: field is absent, the From: field has conflated semantics, as both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments the altered use of the From: field, by specifying the Author: field, which identifies the original author of the message and is not subject to modification by Mediators. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER", Ran Chen, BenChong Xu, 2020-09-27, This draft specify 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, 2020-09-27, 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. "InternetWide Identities with Realm Crossover", Rick van Rein, 2020-09-28, Domains and domain user identities are available in many protocols, and can be expressed as part of the URI grammar. This document outlines how clients can bring their self-controlled identities over when crossing over to foreign realms that rely on authenticated user identities. "YANG data model for BGP Segment Routing Extensions", krishnadeevi, Kamran Raza, Kausik Majumdar, Bruno Decraene, 2021-01-11, 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, Kamran Raza, Kausik Majumdar, Bruno Decraene, Zhichun Jiang, 2021-01-11, This document defines a YANG data model that can be used to configure and manage Segment Routing TE extensions in BGP. "IGMPv3 and MLDv2 Survey Report", Olufemi Komolafe, 2020-09-29, The PIM WG intends to progress IGMPv3 and MLDv2 from Proposed Standards to Internet Standards. The WG decided to conduct a survey of operators, vendors and implementors of these and related protocols to gather information about their implementation and deployment. This document presents the results of the survey and briefly summarizes the key findings. The survey indicates that there is widespread deployment and usage of of IGMPv3 and MLDv2, with numerous independent implementations interoperating successfully. No major issues with either protocol were identified and, similarly, no major unused features in the specifications were highlighted. These findings suggest that IGMPv3 and MLDv2 are indeed ready for progression to Internet Standards. "Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms", Deepti Rathi, Kapil Arora, Shraddha Hegde, Zafar Ali, Nagendra Nainar, 2020-12-07, Segment routing supports the creation of explicit paths using adjacency- sids, node-sids, and anycast-sids. The SR-TE paths are built by stacking the labels that represent the nodes and links in the explicit path. A very useful Operations And Maintenance (OAM) requirement is to be able to ping and trace these paths. A simple mpls ping/traceroute mechanism comprises of ability to traverse the SR-TE path without having to validate the control plane state. This document describes mpls ping and traceroute procedures using Nil FEC with additional extensions. "APN Security and Privacy Considerations", Shuping Peng, Zhenbin Li, Daniel Voyer, Cong Li, Peng Liu, Chang Cao, 2020-09-29, APN (Application-aware Networking) architecture aims to convey Application-aware Information including application/user/flow identifiers and SLA/service requirements along with the data packets into the network and make the network aware of applications and their requirements in order to provide corresponding application-aware network services and guarantee their SLA requirements. There have been challenges of the privacy and security issues that could potentially be introduced by conveying the application-aware information into the network. This document describes the security and privacy considerations of APN in various possible scenarios wherein APN will be deployed. "Revised BGP Maximum Prefix Limits Outbound", Melchior Aelmans, stucchi-lists@glevia.com, Job Snijders, 2020-10-16, This document updates RFC4271 by adding a control mechanism which limits the negative impact of outbound route leaks (RFC7908) in order to prevent resource exhaustion in Border Gateway Protocol (BGP) implementations. "Use of P4 Programs in IETF Specifications", Hemant Singh, Marie-Jose Montpetit, 2020-09-30, The IETF specifies several algorithms operating in the data plane of a network node, including liveliness detection, congestion control, network measurement, security, and load balancing. Such algorithms are commonly specified using English or flow charts. As an alternative, this document proposes that P4 programs can be used to specify some data plane algorithms. P4 is a programming language created in 2014 to program the data plane of network nodes such as switches, routers, smartNICs, and generic compute targets. "An Interoperability Architecture for Blockchain Gateways", Thomas Hardjono, Martin Hargreaves, Ned Smith, 2020-10-26, 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. "Quantum-Resistant GSS-API Key Exchange for SSH", Hubert Kario, 2020-10-01, This document specifies additions and amendments to RFC4462. It defines a new key exchange method that uses GSS-API in a way to provide key exchange method that is resistant to attacks by quantum computers. The purpose of this specification is to provide an easy- to-implement upgrade to environments that require resistance against quantum computers before widely accepted post-quantum cryptography algorithms are established. "IP Point to Point Ethernet subnet model", Ole Troan, 2020-10-06, Ethernet topology is no longer a shared medium. It is a long time since Ethernet has been a thick yellow cable snaking its way from station to station. Ethernet is now effectively deployed in a hub and spoke topology. With a point to point link between a host and the network device. This memo describes a set of simplications for how to run IP over such links, where the physical topology is exposed in the network layer topology. "Use of Internationalized Email Addresses in EPP protocol", Dmitry Belyavsky, James Gould, 2020-11-19, This document permits usage of Internationalized Email Addresses in the EPP protocol. The Extensible Provisioning Protocol (EPP), being developed before appearing the standards for Internationalized Email Addresses (EAI), does not support such email addressed. This document describes an EPP extension that allows EAI addresses to be used with an EPP object mapping like the EPP contact mapping. TO BE REMOVED on turning to RFC: The document is edited in the dedicated github repo (https://github.com/beldmit/eppeai). Please send your submissions via GitHub. "Open Digital Asset Protocol", Martin Hargreaves, Thomas Hardjono, 2020-11-01, 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). "IPv6 Neighbor Discovery Overlay Multilink Network Interface (OMNI) Option", Fred Templin, Tony Whyman, 2021-01-01, This document defines a new IPv6 Neighbor Discovery (ND) option termed the "Overlay Multilink Network Interface (OMNI) Option". The OMNI option may appear in any IPv6 ND message type; it is processed by interface types that recognize the option and ignored by all other interface types. The option supports functions such as prefix registration and multilink coordination, and is extensible to support additional functions in the future. "Processing of the Hop-by-Hop Options Header", Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra, 2021-01-21, This document describes the processing of the Hop-by-Hop Options Header (HBH) in today's routers in the aspects of standards specification, common implementations, and default operations. This document outlines the reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how the HBH could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The Hop-by- Hop Options Header is taken into consideration by several network operators as a valuable container for carrying the information facilitating the introduction of new services. The desired, and proposed, processing behavior of the HBH and the migration strategies towards it are also suggested. "The 'haptics' Top-level Media Type", Yeshwant Muthusamy, Chris Ullrich, 2020-11-15, 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?=, 2020-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. "How often and how long should IETF virtual meetings be?", Michael Richardson, 2020-11-28, This document recommends a model for IETF virtual meetings that emphasizes new work, community building and cross-area concerns. This document recommends virtual meetings be planned a reduced amount of overlap among sessions, with short sessions with generous gaps. "Resource Allocation Strategy for Latency Sensitive IoT Traffic", Choong Hong, Shashi Pandey, Yan Tun, Sabah Suhail, Kitae Kim, 2020-10-13, An efficient resource allocation scheme directly affects the overall system's network utilization, and notably, the wireless resource such as bandwidth is itself an expensive commodity. In this regards, to address the requirement of massively increased IoT traffic at the edge, as a solution approach, a number of small cell base stations (SBSs) have been deployed with certain computational capabilities. However, it is still limited, and any inappropriate resource allocation scheme for the associated nodes with traffic characterized by ultra-reliability and low-latency (URLLC) requirements can impact the system's resource utilization and performance. Considering a reserve resource for such kind of traffic, the resource allocation problem in each time slot behaves as a node selection problem with contention amongst active nodes for the resource. In this paper, we have formulated this as an index problem, and with simulation results have shown that the cumulative reward in terms of network utility is maximized following this approach. "Resource Sharing in Virtualized Wireless Networks: A Two-Layer Game Approach", Choong Hong, Yan Tun, Kitae Kim, Seok Kang, Shashi Pandey, 2020-10-13, Wireless network virtualization is one of the auspicious approach to address the increasing demand of mobile data services. It enables logically decoupling the traditional cellular network into infrastructure providers (InPs) and mobile virtual network operators (MVNOs). It also offers a virtualized wireless network (VWN), efficient resource utilization, and isolation between network slices (i.e., MVNOs). In this paper, we consider wireless network slicing for a single InP who owns radio resources and multiple MVNOs who need radio resources to provide specific services to their mobile users. One of the challenges in wireless network slicing is how to efficiently allocate the limited radio resources available at the InP to the MVNOs. In this paper, we address the problem of efficient allocation of the InP radio resources to the MVNOs which aims to maximize the total network capacity of the InP. To this end, we decompose our considered problem into two phases. The first phase is an efficient allocation of the InP radio resources (bandwidth) to the MVNOs, and the second phase is an optimal allocation of MVNOs resources gained from the InP to their mobile users. We then propose a Generalized Kelly Mechanism framework and the Karush-Kuhn- Tucker (KKT) conditions to solve the first and the second phase of our resource allocation problem, respectively. "MSYNC", Sophie Bale, Remy Brebion, Guillaume Bichot, 2020-10-13, 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. "Discovering And Accessing Software Bills of Materials", Eliot Lear, Scott Rose, 2020-10-13, Software bills of materials (SBOMs) are formal descriptions of what pieces of software are included in a product. This memo specifies a different means for SBOMs to be retrieved. "FSM health status support in BFD", Palpandi Perumal, 2020-10-13, Bidirectional Forwarding Detection operates in different modes. When BFD runs in asynchronous mode requires hello packet needs to be transmitted and received on regular intervals. In software based BFD application, hello packets processing path may be heavy weight which may involve many processing levels to reach BFD application. On a scaled system, processing delay may not be constant at all the time and this processing delay does appear at any point between software path entry point and BFD application. This delay needs to be identified and suppressed otherwise system may end up on false link failure detection. This internet draft deals on this particular case. Since introducing new Diagnostic bit, it requires to update RFC5880. "BGP extensions of SR policy for path protection", Liu Yao, Shaofu Peng, 2020-10-14, This document proposes extensions of BGP in order to provide path protection within a candidate path when delivering SR policy. And it also extends BGP-LS to provide some extra information of the segment list in a candidate path in the advertisement. "User Centric Assignment and Partial Task Offloading for Mobile Edge Computing in Ultra-Dense Networks", Choong Hong, Chit Zaw, Seok Kang, 2020-10-14, By collocating servers at base stations, Mobile Edge Computing (MEC) provides low latency to users for real time applications such as Virtual Reality and Augmented Reality. To satisfy the growing demand of users, base stations are deployed densely in highly populated areas. Coordinated Multipoint Transmission (CoMP) allows users to connect to multiple base stations simultaneously. In ultra-dense networks, by offloading the partials of tasks to different base stations, users can achieve lower latency and utilize the computation ability of the surrounding base stations. To control the signaling overhead, the number of base stations that can be connected should be limited. In this paper, we propose a user-centric base station assignment algorithm by considering the possible load of base stations. Moreover, a partial task offloading algorithm is proposed to utilize the computation of under-loaded base stations. Resource allocation is then solved by convex optimization. "Edge AI assists Partial Content Caching with Smart Content Prefetching Scheme", Choong Hong, Kyi Thar, Kitae Kim, Seok Kang, 2020-10-15, Watching videos (Contents) from mobile devices has been causing most of the network traffic and is projected to remain to increase exponentially. Thus, numerous types of content and chunk based caching schemes have been proposed to handle the increasing traffic. Those caching schemes cache the whole videos at the edge nodes, but most of the users view only the beginning of the videos. Hence, caching the complete video on the edge node is an ineffective solution to reduce the network traffic as well as to improve the cache utilization. Thus, a chunk-level caching scheme to store popular videos partially and a smart prefetching scheme is needed to provide the missing chunks of the video. This Internet-Draft will expire on August 09, 2021. "Connection Migration in QUIC", Lizhuang Tan, Xiaochuan Gao, Wei Su, Na Li, Wei Zhang, 2020-10-15, This document explores and classifies QUIC connection migration, and suggests possible improvements. "IPv6 Deployment Status", Giuseppe Fioccola, Paolo Volpato, Nalini Elkins, Sebastien Lourdez, 2020-11-02, Looking globally, IPv6 is growing faster than IPv4 and this means that the collective wisdom of the networking industry has selected IPv6 for the future. This document provides an overview of IPv6 transition deployment status and a view on how the transition to IPv6 is progressing among network operators that are introducing IPv6 or have already adopted an IPv6-only solution. It also aims to analyze the transition challenges and therefore encourage actions and more investigations on some areas that are still under discussion. The overall IPv6 incentives are also examined. "User Centric Assignment and Partial Task Offloading for Mobile Edge Computing in Ultra-Dense Networks", Choong Hong, Chit Zaw, Seok Kang, 2020-10-15, By collocating servers at base stations, Mobile Edge Computing (MEC) provides low latency to users for real time applications such as Virtual Reality and Augmented Reality. To satisfy the growing demand of users, base stations are deployed densely in highly populated areas. Coordinated Multipoint Transmission (CoMP) allows users to connect to multiple base stations simultaneously. In ultra-dense networks, by offloading the partials of tasks to different base stations, users can achieve lower latency and utilize the computation ability of the surrounding base stations. To control the signaling overhead, the number of base stations that can be connected should be limited. In this paper, we propose a user-centric base station assignment algorithm by considering the possible load of base stations. Moreover, a partial task offloading algorithm is proposed to utilize the computation of under-loaded base stations. Resource allocation is then solved by convex optimization. "Proactive energy management for smart city with edge computing using meta-reinforcement learning scheme", Choong Hong, Md. Munir, Kitae Kim, Seok Kang, 2020-10-15, Renewable energy enabled sustainable energy management ensures a high degree of reliability in order to fulfill the energy demand of a smart city. In such case, renewable energy generation is random over time and also energy consumption of smart city users’ is nondeterministic in nature. Therefore, to ensure sustainable energy management for smart city, a proactive energy management scheme should be integrated into smart city network. In which, edge node should be considered as local computational unit for each energy user and microgrid controller should be played the role of energy management decision aggregator. As a result, proactive energy management scheme not only overcomes the challenges of renewable energy-aware demand scheduling but also establishes a strong relationship for both energy generation and consumption over time. Therefore, a distributed mechanism is considered, where the edge node for executing local agent to determine an individual users’ policy with respect to energy consumption and renewable energy generation (users’ own sources). On the other hand, microgrid controller determines meta-policy through a meta-agent with Recurrent Neural Network (RNN). Since a meta-agent accepts local policy as an input with historical observations, which ensures fast and efficient execution of proactive energy management for the smart city. "Secure Crypto Config", Kai Mindermann, Lisa Teis, 2020-10-18, Choosing secure cryptography algorithms and their corresponding parameters is difficult. Also, current cryptography APIs cannot change their default configuration which renders them inherently insecure. The Secure Crypto Config provides a method that allows cryptography libraries to change the default cryptography algorithms over time and at the same time stay compatible with previous cryptography operations. This is achieved by combining three things standardized by the Secure Crypto Config: (1) A process that is repeated every two years, where a new set of default configurations for standardized cryptography primitives is published in a specific format. (2) A Secure Crypto Config Interface that describes a common API to use cryptography primitives in software (3) using COSE to derive the parameters from output of cryptography primitives, otherwise future changes of the default configuration would change existing applications behavior. "Low End-to-End Latency Content Caching in Wireless Network Clouds", Song Chong, Hyeonjoon Jang, 2020-10-18, In this document, we consider the content caching design without requiring historical content access information or content popularity profiles in a hierarchical cellular network architecture. Our design aims to dynamically select caching locations for different contents where caching locations can be content servers, cloud units (CUs), and base stations (BSs). Our design objective is to support as high content request rates as possible while maintaining the finite service time. "QUIC-Aware Proxying Using CONNECT-UDP", Tommy Pauly, David Schinazi, 2020-10-18, This document defines an extension to the CONNECT-UDP HTTP method that adds specific optimizations for QUIC connections that are proxied. 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 through the proxy rather than being re-encapsulated and re-encrypted. "Multipath Communication with Satellite and Terrestrial Links", Joerg Deutschmann, Kai-Steffen Hielscher, Reinhard German, 2020-10-19, Multipath communication enables the combination of low data rate, low latency terrestrial links and high data rate, high latency links (e.g., geostationary satellite links) to provide a full-fledged Internet access. However, the combination of such heterogeneous links is challenging from a technical point of view. This document describes a possible solution, i.e. an architecture and scheduling mechanism. The applicability of this approach to encrypted transport protocols (e.g., Multipath QUIC) is also discussed. "Software-Defined Networking based Policy Driven Network Slicing System", Seokhyun Kim, Hyeonjoon Jang, 2020-10-19, With the advent of Software-Defined Networking(SDN), the network environment has changed greatly to focus on users, and network virtualization technology has made great progress. However, networks that are getting bigger and more advanced have become more and more complex and difficult to use SDN. In such an environment, a network system that users can easily access and use is required. In this document we propose a more advanced policy-based network virtualization system that allows users to select policies and provide networks accordingly, rather than a system that simply virtualizes a network and shares it with each user. "Explicit signaling of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events", Loba Olopade, 2020-10-19, After a renumbering event in an IPv6 network utilizing SLAAC, hosts might continue to use stale addresses, as they are unaware of the changes. Likewise, routers, who may deprecate the use of these prefixes, are unaware of their use on the hosts. This scenario could have an adverse effect on communication with the host. This document proposes changes to the SLAAC algorithm that will explicitly allow routers to learn of these stale prefixes that are still assigned on the network. "Binary Application Record Encoding (BARE)", Drew DeVault, 2020-11-20, The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/public-inbox@lists.sr.ht and/or the author(s). "The Device-to-Device Multi-hop Capability Based On Heterogenous Link Chaining", Hyeonjoon Jang, 2020-10-19, Recently, D2D communication is drawing attention as a technology capable of reducing an excessive load on a network infrastructure and increasing network coverage. When using heterogeneous wireless communication technologies such as WiFi and Bluetooth, which are basically provided to user terminals such as smartphones, the connectivity of D2D communication can be further strengthened. In this paper, we propose a multi-hop communication technique using heterogeneous wireless communication technologies. "Using Short Hierarchical IP Addresses at Edge Networks", Haoyu Song, 2020-10-20, 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 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. 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. "Simple TWAMP (STAMP) Extensions for Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens, 2021-01-12, Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) extensions for Delay and Loss Measurement in Segment Routing networks, for both SR-MPLS and SRv6 data planes. "With System Capability for NETCONF", Chong Feng, Qiufang Ma, 2020-11-02, The NETCONF protocol [RFC6241] defines ways to read configuration and state data from a NETCONF server. In some cases, a client-configured data item refers to a non-existent system generated data item (e.g.,the auto-create interfaces ("eth1") is not yet present). In many situations, the system configured data item doesn't need to be know to the client and client-configured data item will automatically be removed from the operational state datastore and thus only appear in the intended datastore if client-configured data item doesn't exist. In other situations system configured data item needs to be known and overriden by the client. Not all server implementations treat the system configuration data in the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how system configuration are processed by the server, and also defines a new mechanism for client control of server processing of system configuration data. "QUIC Multipath Negotiation Option", Christian Huitema, 2020-10-20, The initial version of QUIC provides support for path migration. In this draft, we argue that there is a very small distance between supporting path migration and supporting simulatneous traffic on multipath. Instead of using an implicit algorithm to discard unused paths, we propose a simple option to allow explicit management of active and inactive paths. Once paths are explicitly managed, pretty much all other requirements for multipath support can be met by appropriate algorithms for scheduling transmissions on specific paths. These algorithms can be implemented on the sender side, and do not require specific extensions, except maybe a measurement of one way delays. "Post-quantum public key algorithms for the Secure Shell (SSH) protocol", Panos Kampanakis, Douglas Steblia, Markus Friedl, Torben Hansen, Dimitrios Sikeridis, 2020-10-21, This document defines hybrid key exchange methods based on classical ECDH key exchange and post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. It also defines post-quantum public key authentication methods based on post-quantum signature schemes. These methods are defined for use in the SSH Authentication Protocol. Note EDNOTE: The goal of this draft is to start the standardization of PQ algorithms in SSH early to mitigate the potential record-and-harvest later with a quantum computer attacks. This draft is not expected to be finalized before the NIST PQ Project has standardized PQ algorithms. After NIST has standardized then this document will replace TBD1, TBD3 with the appropriate algorithms and parameters before proceeding to ratification. EDNOTE: Discussion of this work is encouraged to happen on the IETF WG Mailing List or in the GitHub repository which contains the draft: https://github.com/csosto-pk/pq-ssh/issues . *Change Log* [EDNOTE: Remove befor publicaton]. draft-kampanakis-curdle-pq-ssh-00 * Initial draft "Signature Validation Token", Stefan Santesson, Russ Housley, 2020-10-21, 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. "Automated Certificate Management Environment (ACME) Service Discovery", Fraser Tweedale, 2020-11-16, This document specifies a DNS-based Service Discovery (DNS-SD) profile that enables Automated Certificate Management Environment (ACME) clients to locate ACME servers in their network environment. "Definition of IETF Network Slices", Reza Rokui, Shunsuke Homma, Kiran Makhijani, Luis Contreras, Jeff Tantsura, 2020-12-11, This document provides a definition of the term "IETF Network Slice" for use within the IETF and specifically as a reference for other IETF documents that describe or use aspects of network slices. The document also describes the characteristics of an IETF network slice, related terms and their meanings, and explains how IETF network slices can be used in combination with end-to-end network slices or independent of them. "Multipath Extension for QUIC", Qing An, Yanmei Liu, Yunfei Ma, Zhenyu Li, 2020-10-22, 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 [I-D.ietf-quic-transport]. "Signature Validation Token", Stefan Santesson, Russ Housley, 2020-10-23, This document defines a PDF profile for the Signature Validation Token defined in [SVT]. "Signature Validation Token", Stefan Santesson, Russ Housley, 2020-10-23, This document defines a XML profile for the Signature Validation Token defined in [SVT]. "DetNet Control Plane Signaling", Dirk Trossen, Juergen Schmitt, 2020-10-23, This document provides solutions for control plane signaling, in accordance with the control plane framework developed in the DetNet WG. The solutions cover distributed, centralized, and hybrid signaling scenarios in the TSN and SDN domain. We propose changes to RSVP IntServ for a better integration with Layer 2 technologies for resource reservation, outlining example API specifications for the realization of the revised RSVP (called RSVP-detnet in the document). "Secure Reporting of Update Status", Brendan Moran, 2020-10-23, The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. "Media Types with Multiple Suffixes", Amy Guy, 2021-01-11, This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes. "Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang, Yisong Liu, Ying Cheng, 2020-10-25, This document discusses the redundant ingress router failover in multicast domain. "IP Layer Metrics for 5G Edge Computing Service", Linda Dunbar, Haoyu Song, John Kaippallimalil, 2020-11-02, This draft describes the IP Layer metrics and methods to measure the Edge Computing Servers running status and environment for IP networks to select the optimal Edge Computing server location in 5G Edge Computing (EC) environment. Those measurements are for IP network to dynamically optimize the forwarding of 5G edge computing service without any knowledge above IP layer. "OSPF extension for 5G Edge Computing Service", Linda Dunbar, Huaimo Chen, Aijun Wang, 2020-12-18, This draft describes an OSPF extension to distribute the 5G Edge Computing App running status and environment, so that other routers in the 5G Local Data Network can make intelligent decision to optimize forwarding of flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services. "User Devices Explicit Monitoring", Mauro Cociglio, Massimo Nilo, Fabio Bulgarella, Giuseppe Fioccola, 2020-10-27, 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. "IPv6 Solution for 5G Edge Computing Sticky Service", Linda Dunbar, John Kaippallimalil, 2020-12-18, This draft describes an IPv6 solution that enables packets from an application on a UE (User Equipment) sticking to the same application server location when the UE moves from one 5G cell site to another. "Revised Cookie Processing in the IKEv2 Protocol", Valery Smyslov, 2020-10-28, 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. "IAB COVID-19 Workshop: Interconnection Changes in the United States", Francesco Bronzino, Elizabeth Culley, Nick Feamster, Shinan Liu, Jason Livingood, Paul Schmitt, 2020-10-28, During the early weeks and months of the COVID-19 pandemic, significant changes to Internet usage occurred as a result of a sudden global shift to people working, studying and quarantining at home. One aspect that this affected was interconnection between networks, which this paper studies. This paper explores some of the effects of these changes on Internet interconnection points, in terms of utilization, traffic ratios, and other performance characteristics such as latency. "Distributed SUIT Architecture Model", Jong-Hyouk Lee, J., PARK, 2020-10-28, The management of data is entirely centralized on servers in a server client model which leads the servers to be high-value targets for adversaries. Also, firmware consumers fail to download the latest firmware image if the author is disappeared in the server client model. The distribution of network for managing the manifest and firmware image files thus required. This draft introduces a distributed SUIT architecture model, which utilizes blockchains to resolve the issues of the server client model for SUIT. "Specification for a show of hands tool", Martin Duke, 2020-10-28, This is the specification for an experimental show of hands tool for the Meetecho system to be used in online meetings to help chairs quickly poll the meeting. This tool is different from the previous experimental virtual hum tool as it addresses a different use case with different functionality. Following mixed feedback in the IETF 108 post-meeting survey, the experimental virtual hum tool has been withdrawn from the Meetecho client for IETF 109. "An Enhanced Source Routing Header Based on RH3", Han Jie, Wang Huilai, 2021-01-18, IPv6 Routing header type 3 (termed as RH3) is defined and used in Low-Power and Lossy Networks (LLNs) that are typically constrained in resources (limited communication data rate, processing power, energy capacity, memory). Based on the mechanisms introduced by RH3, this document specifies an new IPv6 Routing Header type that provides encapsulation capability of segments with various lengths and can be applied to more scenarios. "An MPLS SR OAM option reducing the number of end-to-end path validations", Ruediger Geib, 2020-10-29, 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. "IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action", Yali Wang, Tianran Zhou, Zhibo Hu, 2020-10-29, This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network. "Recursive Resolvers IP Ranges location distribution and discovery", Emmanuel Bretelle, 2020-10-29, This document specifies a way for recursive resolvers operators to signal the IP ranges and locations used by their server pools. 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/chantra/draft-dns-recursive-iprange-location. "Bidirectional Forwarding Detection (BFD) on Multi-chassis Link Aggregation Group (MC-LAG) Interfaces", Greg Mirsky, Jeff Tantsura, Gyan Mishra, 2020-11-19, 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". "Blockchain Gateways: Use-Cases", Aetienne Sardon, Thomas Hardjono, 2020-10-29, In the past five years there has been a growing interest in using blockchains and DLT systems as a means to create a new mechanism to issue, distribute and manage virtual assets. However, as DLT systems consisting of peer-to-peer (P2P) network of nodes increase in number, there is an increasing need to interconnect these networks to permit virtual assets to flow into and out of them. This document captures a number of use-cases driving the need for interoperability between DLT systems. "Handling and Adoption of Internet-Drafts by IETF Working Groups", Adrian Farrel, Dave Crocker, Brian Carpenter, Fernando Gont, Michael Richardson, 2020-10-29, The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. "SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)", Gyan Mishra, Alexandre Petrescu, Naveen Kottapalli, Dusan Mudric, Dmytro Shytyi, 2020-10-30, This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 65 in PIO, for example, would be permitted to form an addresses whose interface identifier length is length 63, which allows several benefits. 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, 2020-10-30, 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, 2020-10-30, 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. "Quantum Error Correction Inapplicable to Really Entangled States", Masataka Ohta, 2020-10-30, Though quantum error correction assumes localized error model of Shor that errors on a qubit are caused by interaction with its local environment, enabling essentially classical error correction for unentangled states, the model is applied to entangled states improperly without involving local environment states in the entanglement. That is, when an entangled state (Q) is represented as superposition of unentangled terms (Qi) as Q=Q1+Q2+...+Qn, local environment states around qubits are, in general, different term by term. Q will be, with term-specific error operators (Ei), E1*Q1+E2*Q2+...+En*Qn, not, with a common error operator (E) assumed by Shor, E*(Q1+Q2+...+Qn). A complication is that Shor's error model is a little quantum, allowing for two different local environment states around a qubit. As such, quantum error correction is applicable to some trivially entangled states including states used by Shor code but not to really entangled states. "Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration", Jiankang Yao, Linlin Zhou, Hongtao Li, Ning Kong, Wil Tan, Jiagui Xie, 2020-12-05, This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a non-standard proprietary extension. "BGP SR Policy Extensions for Virtual Transport Network", Jie Dong, Zhibo Hu, Ran Pang, 2020-10-30, 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 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 Payload", C. Tjhai, Tobias Heider, Valery Smyslov, 2020-10-30, 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 describes the mechanisms and considerations to exchange such large key-establishment data in IKEv2. "DNS Error Reporting", Roy Arends, Matt Larson, 2020-10-30, 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. "QRT: QUIC RTP Tunnelling", Sam Hurst, 2020-10-30, QUIC is a UDP-based transport protocol for stream-orientated, congestion-controlled, secure, multiplexed data transfer. RTP carries real-time data between endpoints, and the accompanying control protocol RTCP allows monitoring and control of the transfer of such data. With RTP and RTCP being agnostic to the underlying transport protocol, it is possible to multiplex both the RTP and associated RTCP flows into a single QUIC connection to take advantage of QUIC features such as low-latency setup and strong TLS-based security. "Realizing Network Slices in IP/MPLS Networks", Tarek Saad, Vishnu Beeram, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, 2020-12-22, 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. "Dynamic-Anycast in Compute First Networking (CFN-Dyncast) Use Cases and Problem Statement", Liang Geng, Peng Liu, Peter Willis, 2020-10-30, Service providers are exploring the edge computing to achieve better response time, control over data and carbon energy saving by moving the computing services towards the edge of the network in scenarios of 5G MEC (Multi-access Edge Computing), virtualized central office, and others. Providing services by sharing computing resources from multiple edges is emerging and becoming more and more useful for computationally intensive tasks. The service nodes attached to multiple edges normally have two key features, service equivalency and service dynamism. Ideally they should serve the service in a computational balanced way. However lots of approaches dispatch the service in a static way, e.g., to the geographically closest edge, and they may cause unbalanced usage of computing resources at edges which further degrades user experience and system utilization. This draft provides an overview of scenarios and problems associated. Networking taking account of computing resource metrics as one of its top parameters is called Compute First Networking (CFN) in this document. The document identifies several key areas which require more investigations in architecture and protocol to achieve the balanced computing and networking resource utilization among edges in CFN. "A Yang Data Model for IETF Network Slice NBI", Bo Wu, Dhruv Dhody, Liuyan Han, Reza Rokui, 2020-11-15, This document provides a YANG data model for the IETF Network Slice NBI (Northbound Interface). The model can be used by a higher level system which is the IETF Network Slice consumer of an IETF Network Slice Controller (NSC) to request, configure, and manage the components of an IETF Network Slice. The YANG modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Architecture of Dynamic-Anycast in Compute First Networking (CFN- Dyncast)", Li Yizhou, Luigi Iannone, Jianfei(Jeffrey) HE, Liang Geng, Peng Liu, Yong Cui, 2020-10-31, Compute First Networking (CFN) Dynamic Anycast refers to in-network edge computing, where a single service offered by a provider has multiple instances attached to multiple edge sites. In this scenario, flows are assigned and consistently forwarded to a specific instance through an anycast approach based on the network status as well as the status of the different instance. This document describes an architecture for the Dynamic Anycast (Dyncast) in Compute First Networking (CFN). It provides an overview, a description of the various components, and a workflow example showing how to provide a balanced multi-edge based service in terms of both computing and networking resources through dynamic anycast in real time. "Guidance on End-to-End E-mail Security", Daniel Gillmor, 2020-10-31, 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. "Extension of Transport Aware Mobility in Data Network", Kausik Majumdar, Uma Chunduri, Linda Dunbar, 2020-10-31, 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 NLRI App Meta Data for 5G Edge Computing Service", Linda Dunbar, Kausik Majumdar, Haibo Wang, 2020-11-02, This draft describes a new BGP Network Layer Reachability Information (BGP NLRI) Path Attribute, AppMetaData, that can distribute the 5G Edge Computing App running status and environment, so that other routers in the 5G Local Data Network can make intelligent decision on optimized forwarding of 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). "Scenarios for Flexible Address Structure", Yihao Jia, Guangpeng Li, Sheng Jiang, 2020-10-31, Along as the adoption of TCP/IP in increasingly emerging scenarios, challenges emerge as well due to the ossified address structure. To still enable TCP/IP for networks that previously using exclusive protocols, a flexible address structure would be highly preferred for their particular properties. This document describes well-recognized scenarios that typically require a flexible address structure, and states the requirements of such flexible address structure. "Flexible IP: An Adaptable IP Address Structure", Yihao Jia, Zhe Chen, Sheng Jiang, 2020-10-31, Along as the popularization and adoption of IP in emerging scenarios, challenges emerge as well due to the ossified address structure. To enable TCP/IP in networks that previously using exclusive protocol, a flexible address structure would be far more preferred for their particular properties [draft-jia-scenarios-flexible-address-structure]. This document describes a flexible address structure -- Flexible IP (FlexIP) acting on limited domains [RFC8799]. FlexIP is expected to proactively adapt scenarios under flexible address structure. Meanwhile, FlexIP still benefit from global reachability based on the IPv6 interoperability. "MAC address randomization", Juan Zuniga, Carlos Bernardos, Amelia Andersdotter, 2020-11-01, 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, Daniel Voyer, Bin Wen, Luay Jalil, 2020-11-02, 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, 2020-11-01, 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) "JMAP Blob management extension", Bron Gondwana, 2020-11-15, The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP PUT and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to handle Blobs, by making inline method calls within a standard JMAP request. "RDAP Redirect with Content", Tom Harrison, George Michaelson, 2020-11-01, The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. When an RDAP service operator has delegated authority for a resource to a third party, the operator will configure its RDAP service to redirect requests for that resource to the third party. However, the client may be interested in the resource registration data that the first service operator has in its own right, for various reasons. This document defines a conformance code that a service operator can use to indicate that when redirecting requests, it will also include as the body of the response the RDAP object (if any) that it has in its own right for the requested resource. "light weithted vul record", Jiang Li, Jun Fu, Xiaoxiao Li, Yexia Cheng, 2020-11-01, Vulnerability information will be recorded in risk detection and scanning. If a vulnerability is detected in a host during one scan, a record will be generated and added to the database, together with a time-stamp when the vulnerability is detected. If risk detection is carried out periodically, a series of records will be generated for each detection, until vulnerability is fixed. At present, a common way to record vulnerabilities is a vulnerability--a detection--a record, a vulnerability--N detections--N records(N>1).In this way, the number of vulnerability records is related to the rounds of detection. In the case that the number of existing vulnerabilities remains unchanged, more frequent vulnerabilities are scanned, more records are recorded In this document, a light weighted vulnerability recording method is proposed. To make that, in the whole life cycle of a vulnerability, only one record is generated after multiple detections. "Separation of Data Path and Data Flow Sublayers in the Transport Layer", Hirochika Asai, 2020-11-01, This document reviews the architectural design of the transport layer. In particular, this document separates 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. 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. "Compressed SRv6 SID List Requirements", Weiqiang Cheng, 2021-01-11, This document specifies requirements for solutions to compress SRv6 SID lists. "Data-driven Accounting in Application-aware IPv6 Networking", Zongpeng Du, Peng Liu, Liang Geng, 2020-11-02, This document introduces a new usecase of Application-aware IPv6 Networking to enable data-driven accounting. "Network measurement intent", Hongwei Yang, Danyang Chen, Kehan Yao, 2020-11-02, 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. "Requirements of computing and network joint optimization and scheduling", Yuexia Fu, Peng Liu, Liang Geng, 2020-11-02, With the development of edge computing, there is a trend that computing is widely deployed in network rather than at other end of network, and provides services at nearer location. With the deep integration of network, traditional optimization and scheduling within network domain is not enough, the endpoint of the path matters a lot. So the relationship between computing and network are new and important topics to be studied. This document focus on the requirements of computing and network joint optimization and scheduling based on the newly arising service requirements. "Centralized Control and Distributed Function Slicing for Fast Connection Establishment and Fault Recovery in Optical Networks", Li Xin, Lu Zhang, Jianghua Wei, Ying Tang, Shanguo Huang, 2020-11-02, Optical networks which support a large number of emerging applications, such as 5G, Cloud Computing, Big Data, Internet of things, autonomous driving, etc., play an increasingly important role in the current world. All the time spectrum resources in optical networks have been treated equally. All spectrum resources form a resource pool which is allocated to applications bit by bit until it is all used up. Although this pattern reduces the complexity of resource maintenance, it has poor flexibility and high operation complexity for different types of applications. This draft proposes a framework of centralized control and distributed function slicing for fast connection establishment and fault recovery in optical networks. The proposed framework divides all spectrum resources into four functional areas, i.e., optical channel area, fault recovery area, resource pool area, and the reserved functional area. A functional area is responsible for a specific network function. This framework improves the flexibility of optical networks and can achieve fast connection establishment and fault recovery for the request with a highest service level. "SRv6 SPAN", Zhiqiang Li, Tao Sun, Cheng Wei, Junjie Wang, 2020-11-02, As an important means for operation and maintenance (O&M), mirroring is the most direct and comprehensive technology for capturing data streams and forwarding information. Compared with other visualization technologies, it can not only obtain the content of an entire packet, but also add forwarding information of a network device to a mirror packet and send the packet to a remote analysis server. "NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof Hagsand, Hongwei Li, 2020-11-02, In some circumstance, a server may contain many instances of a particular YANG list or leaf-list. Retrieval of the entire list or leaf-list at once can be extremely inefficient. This document defines a YANG data model with "get-pageable-list" RPC to allow a client to iterate through a large list, in a manner that is most efficient for the application. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. "DC aware TE topology model", Young Lee, Xufeng Liu, Luis Contreras, 2020-11-02, This document proposes the extension of the TE topology model for including information related to data center resource capabilities. "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof Hagsand, Hongwei Li, 2020-11-02, In some circumstance, a server may contain many instances of a particular YANG list or leaf-list. Retrieval of the entire list or leaf-list at once can be extremely inefficient. Pagination mechanisms are needed to allow a client to iterate through a large list, in a manner that is most efficient for the application. This document Updates RFC 8040 to declare "list" and "leaf-list" as resource targets for the RESTCONF operations such as GET, POST operations. "Segment Routing for Redundancy Protection", Xuesong Geng, Mach Chen, Fan Yang, 2020-11-02, Redundancy protection is one of the mechanisms to achieve service protection, following the principle of PREOF (Packet Replication/ Elimination/Ordering Function). To empower the Segment Routing with the capability of redundancy protection, two types of Segment including Redundancy Segment and Merging Segment are introduced. The instantiation of Redundancy and Merging Segments can be applied to both segment routing over MPLS (SR-MPLS) and segment routing over IPv6 (SRv6). "Network Monitoring For IGP", Yunan Gu, Shuanglong Chen, Huanan Chen, Zhenbin Li, 2020-11-02, To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. This document proposes network monitoring for IGP to facilitate troubleshooting by collecting the IGP monitoring data and reporting it to the network monitoring server in real-time. In this document, the operations of network monitoring for ISIS are described, and the corresponding network monitoring message types and message formats are defined. "Tunneling Internet protocols inside QUIC", Maxime Piraux, Olivier Bonaventure, Adi Masputra, 2020-11-02, This document specifies methods for tunneling packets of Internet protocols inside a QUIC connection. "Multilevel configuration", Dean Bogdanovic, Xufeng Liu, Luis Contreras, 2020-11-02, This document describes issues caused by residual configurations in network devices and how multi-level configuration could potentially offer a solution. "Session mode for multiple QUIC Tunnels", Maxime Piraux, Olivier Bonaventure, Adi Masputra, 2020-11-02, This document specifies methods for grouping QUIC tunnel connections in a single session enabling the exchange of packets of Internet protocols over several QUIC connections. "Tunneling TCP inside QUIC", Maxime Piraux, Olivier Bonaventure, 2020-11-02, This document specifies a new operating mode for a QUIC tunnel to efficiently convey TCP bytestreams. "MPLS IANA Registries Structure", Loa Andersson, 2020-11-02, The structure of the MPLS IANA registries is not entirely intuitive. This document proposes a clarification. The intention is to make a structure that is implicit in the MPLS IANA registries clearly visible. This document does not change any RFC, nor are the content of any registry touched. "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, 2020-11-19, 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, 2020-11-16, 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. "Delegation Information (Referrals) Signer for DNSSEC", Kazunori Fujiwara, 2020-11-02, DNSSEC does not protect delegation information, it contains NS RRSet on the parent side and glue records. This document defines delegation information signer (DiS) resource record for protecting the delegation information, by inserting on the parent side of zone cut to hold a hash of delegation information. The DiS resource record reuses the type code and wire format of DS resource record, and distinguishes it from existing DS RRSet by using a new digest type. This document also describes the usage of DiS resource record and shows the implications on security-aware resolvers. The definition and usage are compatible with current DNSSEC. "Explicit Flow Measurements Techniques", Mauro Cociglio, Alexandre Ferrieux, Giuseppe Fioccola, Igor Lubashev, Fabio Bulgarella, Isabelle Hamchaoui, Massimo Nilo, Riccardo Sisto, Dmitri Tikhonov, 2020-11-02, 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. "IETF Network Slice Controller and its associated data models", Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody, Sergio Belotti, 2020-11-02, This document describes the major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slices and their realization. "IETF Network Slice for 5G and its characteristics", Reza Rokui, Shunsuke Homma, Xavier de Foy, Luis Contreras, Philip Eardley, Kiran Makhijani, Hannu Flinck, Rainer Schatzmayr, Ali Tizghadam, Christopher Janz, Henry Yu, 2020-11-02, 5G Network slicing is an approach to provide separate independent end-to-end logical network from User Equipment (UE) to various mobile applications where each network slice has its own Service Level Agreement (SLA) and Objectives (SLO) requirements. Each end-to-end network slice consists of a multitude of contexts across RAN, Core and transport domains each with its own controller. To provide automation, assurance and optimization of the 5G the network slices, a 5G E2E network slice orchestrator is needed which interacts with controllers in RAN, Core and Transport network domains. The interfaces between the 5G E2E network slice orchestrator and RAN and Core controllers are defined in various 3GPP technical specifications. However, 3GPP has not defined a similar interface for transport network. The aim of this document is to describe E2E network slicing and its relation to "IETF network slice" for 5G use-case. It also provides an information model for control and mangement of IETF network slices for 5G. "ALTO Multi-Domain Extension: Challenges, Existing Efforts and Next Steps", Qiao Xiang, Y. Yang, 2020-11-02, The emerging multi-domain applications, such as flexible interdomain routing, distributed, federated machine learning and multi-domain collaborative dataset transfer, can benefit substantially from getting information from networks. The ALTO base protocol [RFC7285] provides a northbound interface for applications to retrieve the network information. In particular, it specifies the communication between an ALTO client and an ALTO server, where the ALTO is implicitly assumed to be able to answer any query from the ALTO client. However, it does not specify the cases when the network information are originated from multiple domains (i.e., administrative entities or geographically partitions). This document summarizes the discussion on the ALTO weekly meeting since IETF 108 on how to extend ALTO to support multi-domain applications. It identifies the key challenges for retrieving network information from multiple networks, reviews the existing efforts in the work group, and discusses the next steps to fully address the challenges. "A Simplified Scalable E-Line Service Model with Segment Routing Underlay", Sami Boutros, Siva Sivabalan, Jim Uttaro, Daniel Voyer, Bin Wen, Luay Jalil, 2020-11-02, 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. "Transport aware 5G mobility with PPR", Uma Chunduri, Luis Contreras, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley, 2020-11-02, This document describes few 5G mobility scenarios and how mobile network functions map its SST criteria to identifiers in IP packets that transport segments use to grant transport layer services. This is based on mapping between mobile and IP transport underlays (IPv6, MPLS, IPv4) and a new transport network underlay routing mechanism, Preferred Path Routing (PPR), which brings slice properties and works with any underlying transport (L2, IPv4, SR and MPLS) is described. "Privacy Pass: Centralization Problem Statement", Mark McFadden, 2020-11-02, This document discusses the problems and mitigations 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, 2020-11-02, 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, Daniel Voyer, Bin Wen, Luay Jalil, 2020-11-02, 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, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2020-11-02, 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. "YANG Data Model for Network Slice Per-Hop Definition", Tarek Saad, Vishnu Beeram, 2020-11-02, This document defines a YANG data model for the management of Network Slice Per-Hop Definitions (Slice-PHDs) on network slicing capable nodes in IP/MPLS networks. "Endpoint Security Classification", Mark McFadden, 2020-11-02, It seems reasonable to suggest that, despite the huge variety of types of endpoints on the Internet, there are categories of similarity. These categories are important because categories of endpoint devices may share particular advantages or limitations for endpoint security. This draft attempts to suggest a classification of endpoints as a foundation for further work on operational security. The goal is to identify classes of endpoints with similar characteristics. Those characteristics may lead to the discovery that the devices in a particular category share similar characteristics for endpoint security. "Multicast Network Address Translation", Jake Holland, 2020-12-23, This document defines a method for a network to maintain Network Address Translation address mappings for the transport of globally addressed multicast traffic within a network that can't otherwise forward the globally addressed traffic. A new Multicast Network Address Translation (MNAT) service is defined to communicate the address mappings to ingress and egress points within the network, and considerations for operation of the MNAT service are described. "BIER Fast ReRoute", Huaimo Chen, Aijun Wang, Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2020-11-02, This document describes a mechanism for fast re-route (FRR) protection against the failure of a node or link in the core of a "Bit Index Explicit Replication" (BIER) domain. It does not have any per-flow state in the core. For a multicast packet to traverse a node in the domain, when the node fails, its upstream hop as a PLR reroutes the packet around the failed node once it detects the failure. "Additional data fields for IOAM Trace Option Types", Barak Gafni, Hongqiang Liu, Rui Miao, Mickey Spiegel, 2020-11-02, 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 additional data fields and associated data types to be added to the IOAM data fileds described in [I-D.ietf-ippm-ioam-data]. In-situ OAM data fields can be encapsulated into a variety of protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension header), or IPv4. "IKEv2 support for per-queue Child SAs", Antony Antony, Steffen Klassert, Paul Wouters, 2020-11-02, This document defines two Notification Payload (NUM_QUEUES and QUEUE_INFO) for the Internet Key Exchange Protocol Version 2 (IKEv2). These payloads add support for negotiating multiple identical Child SAs that can be used to to optimize performance based on the number of queues or CPUs, orcw to create multiple Child SAs for different Quality of Service (QoS) levels. Using multiple identical Child Sa's has the additional benefit that multiple streams have their own Sequence Number, ensuring that CPU's don't have to synchronize their crypto state or disable their replay window detection. "The CONNECT-IP method for proxying IP traffic", Mirja Kuehlewind, Magnus Westerlund, Marcus Ihlar, Zaheduzzaman Sarker, 2020-11-02, This draft specifies a new HTTP/3 method CONNECT-IP to proxy IP traffic. CONNECT-IP can be used to convert a QUIC stream into a tunnel or initialise an HTTP datagram flow to a forwarding proxy. Each stream or HTTP datagram flow can be used separately to establish forwarding of an IP flow to potentially different remote hosts. To request forwarding, a client connects to a proxy server by initiating a HTTP/3 connection and sends a CONNECT-IP indicating the address of the target server. The proxy server then forwards payload received on that stream or in an HTTP datagram with a certain flow ID to the target server after adding an IP header to each of the frames received. "A Simplified Scalable L3VPN Service Model with Segment Routing Underlay", Sami Boutros, Siva Sivabalan, Jim Uttaro, Daniel Voyer, Bin Wen, Luay Jalil, 2020-11-02, 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. "Discovery of Equivalent Encrypted Resolvers", Tommy Pauly, Eric Kinnear, Christopher Wood, Patrick McManus, Tommy Jensen, 2020-11-02, This document defines Discovery of Equivalent Encrypted Resolvers (DEER), 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 an encrypted resolver is known. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. This mechanism is designed to be limited to cases where equivalent encrypted and unencrypted resolvers are operated by the same entity. "YANG Data Model for SR Service Programming", Jaganbabu Rajamanickam, Kamran Raza, daniel.bernier@bell.ca, 2020-11-02, 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). "Mathematical Mesh 3.0 Part VI: Mesh Discovery Service", Phillip Hallam-Baker, 2021-01-13, A naming service for the Mathematical Mesh 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 . "ALTO Extension: New Transport Layer Protocols", Kai Gao, 2020-11-02, The current ALTO transport is based on HTTP/1.x connections between ALTO servers and ALTO clients. On the other hand, recent extensions to HTTP/1.x such as HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http] introduce capabilities such as server push and stream multiplexing, which can potentially be integrated into ALTO to improve ALTO capabilities such as incremental updates. This document identifies use cases of ALTO and its extensions that may benefit from the advanced features of HTTP/2 and HTTP/3, and proposes ALTO extensions to fully leverage the benefits. "What To Do With Multiple Active Paths in QUIC", Spencer Dawkins, 2021-01-06, The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases. This document is intended to capture that variety of ideas, to inform further discussion in the working group. "Framework and Data Model for OTN Network Slicing", Haomian Zheng, Italo Busi, Aihua Guo, 2020-11-02, The requirement of slicing network resource with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, the OTN has the capability to 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. A YANG data model augmentation 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, 2020-11-02, 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, 2020-11-02, 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. "DNS Private Namespace Options", Wes Hardaker, 2020-11-02, This document discusses the trade-offs between various options about creating a private namespace within top level domains within the root zone. "DNS over HTTPS (DoH) Considerations for Operator Networks", Andy Fidler, Bert Hubert, Jason Livingood, Jim Reid, Nicolai Leymann, 2020-11-02, The introduction of DNS over HTTPS (DoH), defined in RFC8484, presents a number of challenges to network operators. These are described in this document. The objective is to document the problem space and make suggestions that could help inform network operators on how to take account of DoH deployment. This document also identifies topics that may require further analysis. "An Extension of I2NSF Framework for Security Management Automation in Cloud-Based Security Services", Jaehoon Jeong, Patrick Lingga, J., PARK, 2020-11-02, 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. "Messaging Use Cases for STIR", Jon Peterson, Chris Wendt, 2020-11-02, Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is leveraged by bad actors in the text messaging space. This document considers the applicability of STIR's Persona Assertion Token (PASSporT) and certificate issuance framework to instant text and multimedia messaging use cases, both for messages carried or negotiated by SIP, and for non-SIP messaging. "TCP ETS: Extensible Timestamp Options", Kevin Yang, Neal Cardwell, Yuchung Cheng, Eric Dumazet, 2020-11-02, This document presents ETS: an Extensible TimeStamps option for TCP. It allows hosts to use microseconds as the unit for timestamps to improve the precision of timestamps, and advertise the maximum ACK delay for its own delayed ACK mechanism. Furthermore, it extends the information provided in the [RFC7323] TCP Timestamps Option by including the receiver delay in the TSecr echoing, so that the receiver of the ACK is able to more accurately estimate the portion of the RTT that resulted from time traveling through the network. The ETS option format is extensible, so that future extensions can add further information without the overhead of extra TCP option kind and length fields. "Internet Threat Model Evolution: Background and Principles", Jari Arkko, Stephen Farrell, 2020-11-02, 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. "Meeting asynchronously with mailing lists", Mallory Knodel, Karel Novotny, 2020-11-02, For when we can't meet in person, when there's interim work to be done, or just because the task calls for it, an asynchronous text- based meeting can sometimes be perfectly productive and useful. Given how much the IETF uses email already [RFC3934] this document aims to create additional guidance for co-chairs and meeting facilitators who might want to host a meeting asynchronously with mailing lists. Drawing from decades of facilitation experience in global networks, the document also treats unique considerations for facilitators that are introduced by this meeting methodology. "Running an IETF Hackathon", Charles Eckel, 2020-11-18, IETF Hackathons encourage developers to collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. This document provides a set of practices for running IETF Hackathons. "Transaction ID Mechanism for NETCONF", Jan Lindblad, 2020-11-06, TODO Abstract 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/janlindblad/netconf-transaction-id. "Per-Application Networking Considerations", Lorenzo Colitti, Tommy Pauly, 2020-11-15, This document describes considerations for and implications of using application identifiers as a method of differentiating traffic on networks. Specifically, it discusses privacy considerations, possible mitigations, and considerations for user experience and API design. 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/per-app-networking-considerations. "Using Messaging Layer Security (MLS) to Provide Keys for SFrame", Richard Barnes, Raphael Robert, 2020-11-15, Secure Frames (SFrame) defines a compact scheme for encrypting real- time media. In order for SFrame to address cases where media are exchanged among many participants (e.g., real-time conferencing), it needs to be augmented with a group key management protocol. The Messaging Layer Security (MLS) protocol provides continuous group authenticated key exchange, allowing a group of participants in a media session to authenticate each other and agree on a group key. This document defines how the group keys produced by MLS can be used with SFrame to secure real-time sessions for groups. "CUBIC for Fast Long-Distance Networks", Lisong Xu, Sangtae Ha, Lars Eggert, 2020-11-15, CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC. This documents obsoletes [RFC8312], updating the specification of CUBIC to conform to the current Linux version. "Mailing List Manager (MLM) Transformations", Alessandro Vesely, 2020-11-16, 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. "Automated Certificate Management Environment (ACME) Server Capability Advertisements", Fraser Tweedale, 2020-11-16, Automated Certificate Management Environment (ACME) servers typically support only a subset of the ACME identifier types and validation types that have been defined. This document defines new fields for the the ACME directory object to allow servers to advertise their capabilities, assisting clients to select a suitable server. "Identity Header Error Handling", Chris Wendt, 2020-11-16, 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. "The IPv6 Link-Local Address Type Field", Fred Templin, 2020-11-23, IPv6 link-local addresses are formed from the prefix fe80::/10 which is followed by 54 "zero" bits, then followed by a 64-bit Interface Identifier. There are multiple methods for generating link-local addresses, and multiple may be in use by nodes on the same link (and sometimes even the same interface) at the same time. This document defines an IPv6 link-local address "Type" field that identifies the type of link-local address being used. "RADIUS Extension for Certificate-based SSH Authentication", Devendra Vishwakarma, Prakash suthar, Vivek Agarwal, Anil Jangam, 2020-11-17, 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. "The Idempotency HTTP Header Field", Jayadeba Jena, Sanjay Dalal, 2020-11-23, The "HTTP" Idempotency 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. "Key Exchange Without Forward Secrecy is Not Recommended", John Mattsson, 2020-11-18, Key exchange without forward secrecy enables passive monitoring [RFC7258]. Massive pervasive monitoring attacks relying on key exchange without forward secrecy has been reported [I-D.ietf-emu-aka-pfs]. If key exchange without Diffe-Hellan is used, compromise of the long-term authenticatation key enables a passive attacker to compromise past and future sessions. All TLS 1.2 cipher suites without forward secrecy has been marked as NOT RECOMMENDED [RFC8447], and static RSA has been forbidden in TLS 1.3 [RFC8446]. psk_ke does not provide forward secrecy and is NOT RECOMMENDED. This document sets the IANA registration of psk_ke to NOT RECOMMENDED. "A Generic Ciphertext Format", Yaron Sheffer, Gleb Keselman, Yoav Nir, 2021-01-15, This document defines a set of structured headers for encrypted data. The main goal of this format is to enable detection of encrypted data in large data stores, and associating it back to the system where it was created and the key with which it was encrypted. This allows organizations to extend the concept of data governance to encrypted data, and to manage such data even when encrypted by multiple different systems and cloud providers. "JWS Clear Text JSON Signature Option (JWS/CT)", Bret Jordan, Samuel Erdtman, Anders Rundgren, 2021-01-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 (aka "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. "DMARC Fallback Domains", John Levine, 2020-11-20, This document specifies a new tree walk algorithm to find a DMARC Fallback Domain. "NTPv5 use cases and requirements", James Gruessing, 2020-12-29, This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supercede 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, 2020-12-09, This document describes the version 5 of the Network Time Protocol (NTP). "The CDN-Cache-Control HTTP Response Header Field", Stephen Ludin, Mark Nottingham, Yuchen Wu, 2020-11-23, This specification defines an HTTP header field that conveys HTTP cache directives to CDN caches. "OpenMetrics, a cloud-native, highly scalable metrics protocol", Richard Hartmann, Ben Kochie, Brian Brazil, Rob Skillington, 2020-11-25, OpenMetrics specifies today's de-facto standard for transmitting cloud-native metrics at scale, with support for both text representation and Protocol Buffers and brings it into IETF. It supports both pull and push-based data collection. "Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2020-12-02, 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 [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- proxy by a stateless/stateful constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per-client state. "NAT64 Tunnel Protocol", Kasper Dupont, 2020-11-29, This document describes a stateless NAT64 extension which allows for creation of reliable tunnels between islands of IPv6 deployment. "IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White, Shraddha Hegde, Shawn Zandi, 2020-11-29, In dense topologies, such as data center fabrics based on the Clos and butterfly fabric topologies, flooding mechanisms designed for sparse topologies, when used in these dense topologies, can "overflood," or carry too many copies of topology and reachability to fabric devices. This results in slower convergence times and higher resource utilization. The modifications to the flooding mechanism in the Intermediate System to Intermediate System (IS-IS) link state protocol described in this document reduce resource utilization to a minimum, while increaseing convergence performance in dense topologies. Note that a Clos fabric is used as the primary example of a desne flooding topology throughout this document. However, the flooding optimizations described in this document apply to any dense topology. "Trusted Resolution System and Protocol Extension", Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2020-11-29, 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, 2020-11-29, 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, 2020-11-30, This draft describes a lightweight in-band edge-to-edge network round trip time measurement architecture and suggests implementations. "Detecting Malicious Middleboxes In Service Function Chaining", Canh Nguyen, Minho Park, 2020-12-01, This document addresses problems caused by malicious middleboxes and proposes a scheme that can detect them in Service Function Chaining (SFC) by combining two mechanisms: direct and indirect. The direct mechanism injects a tool into the middleboxes to observe and report the state of each middlebox. In contrast, the indirect mechanism creates a probe service chain, which includes trustful middleboxes, to investigate the operation of other middleboxes in the network. "Comparing ALPS and Half-RTT Data", David Benjamin, 2020-12-03, This document compares the Application Layer Protocols Settings extension with the half-RTT feature in TLS 1.3. "IPv6 Hop-by-Hop Options Processing Procedures", Robert Hinden, Gorry Fairhurst, 2020-12-03, 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 in routers more practical with the goal of making IPv6 Hop-by-Hop options useful to deploy in the Internet. When published, this document updates RFC8200. "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", Pascal Thubert, Tim Winter, 2020-12-04, 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. "Questions for Multiple Paths In QUIC", Spencer Dawkins, 2021-01-17, The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases, and so had different assumptions about how applications might use QUIC over multiple paths. This document is intended to capture questions that have come up in discussions, with some suggested answers, to inform further discussion in the working group. "Requirements for P4 Program Splitting for Heterogeneous Network Nodes", Hemant Singh, 2020-12-08, The P4 research community has published a paper to show how to split a P4 program into sub-programs which run on heterogeneous network nodes in a network. Examples of nodes are a network switch, a smartNIC, or a host machine. The paper has developed artifacts to split program based on latency, data rate, cost, etc. However, the paper does not mention any requirements. To provide guidance, this document covers requirements for splitting P4 programs for heterogeneous network nodes. "SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li, 2020-12-08, 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. "Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges", Andrew Biggs, Richard Barnes, 2020-12-08, This document specifies an extension to the ACME protocol [RFC8555] to enable ACME servers to validate a client's control of an email identifier using single sign-on (SSO) technologies. An extension to the CAA [RFC8659] resource record specification is also defined to provide domain owners a means to declare a set of SSO providers that ACME servers may rely upon when employing SSO for identifier validation on their domain. "JSON Schema: A Media Type for Describing JSON Documents", Austin Wright, Henry Andrews, Ben Hutton, Greg Dennis, 2020-12-08, JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", Austin Wright, Henry Andrews, Ben Hutton, 2020-12-08, JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like. "Relative JSON Pointers", Geraint Luff, Henry Andrews, Ben Hutton, 2020-12-08, JSON Pointer is a syntax for specifying locations in a JSON document, starting from the document root. This document defines an extension to the JSON Pointer syntax, allowing relative locations from within the document. "IPv6 Addressing Considerations", Fernando Gont, Guillermo Gont, 2020-12-11, IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. "Multipath Extension for QUIC", Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, Zhenyu Li, 2020-12-15, 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, 2020-12-11, This document defines semantics that allow for signaling a new SDP group "S" for superimposed media in an SDP session. The "S" attribute can be used by the application to relate all the superimposed media streams enabling them to be added as an overlay on top of any media stream. The superimposition grouping semantics is required, if the media data is separate and transported via different sessions. "Using QUIC Datagrams with HTTP/3", David Schinazi, Lucas Pardue, 2021-01-05, 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 defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 by adding an identifier at the start of the frame payload. This allows HTTP messages to convey related information using unreliable DATAGRAM frames, ensuring those frames are properly associated with an HTTP message. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org (mailto:masque@ietf.org)) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/draft-h3-datagram. "An ECN Extension to CONNECT-UDP", David Schinazi, 2021-01-05, The CONNECT-UDP method allows proxying UDP packets over HTTP. This document describes an extension to CONNECT-UDP that allows conveying ECN information on proxied UDP packets. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org (mailto:masque@ietf.org)) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/draft-connect-udp-ecn. "http2 window size use case", chenmeiling, Li Su, 2020-12-13, 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, 2020-12-13, This document proposed the minimum value setting mechanism of HTTP2.0 Window and Window_update, and a Window_update frame sending mechanism. "RIFT Keys Structure and Well-Known Registry in Key Value TIE", Tony Przygienda, 2020-12-13, This document describes key structure of keys contained within RIFT key-value TIEs. "APN Scope and Gap Analysis", Shuping Peng, Zhenbin Li, 2020-12-14, The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an identifier to allow for implementing fine-grain user-, application-, and service-level requirements at the network layer. This document describes the scope of the APN work and the solution gap analysis. "SRv6 In-situ Active Measurement", Haoyu Song, Tian Pan, 2020-12-15, This draft describes an in-band active measurement method for SRv6. A probing packet contains an SRH with a flag bit set. 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. Multiple applications can be supported by the method. "JMAP Sharing", Neil Jenkins, 2020-12-15, This document specifies a data model for sharing data between users using JMAP. "Optimizations for Using TLS Early Data in HTTP/2", Martin Thomson, 2020-12-15, This proposes an extension to HTTP/2 that enables the use of server settings by clients that send requests in TLS early data. In particular, this allows extensions to the protocol to be used. This amends the definition of settings defined in RFC 7540 and RFC 8441 and introduces new registration requirements for HTTP/2 settings. "Using Entropy Label for Network Slice Identification in MPLS networks.", Bruno Decraene, Clarence Filsfils, Wim Henderickx, Tarek Saad, Vishnu Beeram, 2020-12-16, 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, 2020-12-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 network slice 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 network slice along a Segment Routing (SR) path. "On loading MUD URLs from QR codes", Michael Richardson, Jacques Latour, Hassan Gharakheili, 2020-12-17, This informational document details the mechanism used by the CIRA Secure Home Gateway (SHG) to load MUD definitions for devices which have no integrated MUD (RFC8520) support. RFCEDITOR please remove: Pull requests and edit welcome at: https://github.com/CIRALabs/securehomegateway-mud/tree/ietf "A DODAG Metric Used for DODAG Selection in Low-Power and Lossy Networks", Huimin She, Li Zhao, Pascal Thubert, 2020-12-18, This document extends [RFC6551] by defining a new DODAG metric called DODAG size, which can be used for DODAG selection in Low-Power and Lossy Networks (LLNs). DODAG size is an important metric for nodes to decide which DODAG to join, or which DODAG to migrate. This document proposes methods to disseminate DODAG size from the Root to all nodes in the DODAG, so that the DODAG size can be advertised to new joining nodes. "PCAP Capture File Format", Guy Harris, Michael Richardson, 2020-12-21, 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. "JOSE signed Voucher Artifacts for Bootstrapping Protocols", Michael Richardson, Thomas Werner, 2020-12-22, This document describes a serialiation of the RFC8366 voucher format to a JSON format is then signed using the JSON Object Signing and Encryption mechanism described in RFC7515. In addition to explaining how the format is created, MIME types are registered and examples are provided. "The update registries draft", Rich Salz, 2021-01-07, 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. 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-update-registries. "QUIC Performance", Nick Banks, 2020-12-23, The QUIC performance protocol provides a simple, general-purpose protocol for testing the performance characteristics of a QUIC implementation. With this protocol a generic server can support any number of client-driven performance tests and configurations. Standardizing the performance protocol allows for easy comparisons across different QUIC implementations. "CDNI Request Routing Extensions", Nir Sopher, Sanjay Mishra, 2020-12-23, 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, 2020-12-25, The photonic firewall oriented routing and spectrum allocation strategy in elastic optical networks is proposed. For the security detecting requirement, each light-path should pass through at least a photonic firewall. To reduce the blocking rate and improve the spectrum efficiency, the whole network is divided into several parts according to the locations of all deployed photonic firewalls. A photonic firewall is responsible for the security detecting for each part. This strategy has a low complexity and is suitable for large- scale optical networks. "A High-capacity and Real-time LISP Mapping Framework", Wei Mi, Jingguo Ge, 2020-12-27, This draft describes how the LISP mapping framework designed to be have the capability to provide efficient, real-time, high concurrent services when guarantee the scale. "A toxonomy of eavesdropping attacks", Michael Richardson, 2020-12-29, The terms on-path attacker and Man-in-the-Middle Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. This document offers an update on terminology for network attacks. A consistent set of terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. "Architecture and application scenario for fused service function chain", Jinyou Dai, Xueshun Wang, Jun Gao, 2020-12-28, This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. 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. "Discussion of Requirements for ADD", Man Zhang, 2020-12-28, This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, Chuck Lever, 2020-12-30, 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 to enable use of rfcdiff when reviewing such drafts. "Asset Profile Definitions for DLT Interoperability", Aetienne Sardon, Thomas Hardjono, Benedikt Schuppli, 2020-12-30, In order for virtual assets to be traded or exchanged within online transactions, the parties involved in the transaction must have share a common definition of what constitute the virtual asset. Parties transacting on a DLT system must have the unambiguous means to refer to a common definition of an virtual asset, independent of the implementation of the virtual asset in question. This specification defines a JSON representation of a number of common information fields within asset profiles. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, 2020-12-31, 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 8881. In addition to many corrections and clarifications, it relies 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-01-01, This specification defines models and schema definitions facilitating the storage of [X.660] registration data in a Lightweight Directory Access Protocol Directory Information Tree. "Truncated SID Inter Domain Considerations", Shaofu Peng, 2021-01-04, This document introduces a method for interworking between domains of Segment Routing in IPv6 network that use different levels of Segment Identifier's compression. "Scope of Unique Local IPv6 Unicast Addresses", Fernando Gont, 2021-01-05, Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the IPv6 Global Unicast address space. However, the semantics of ULAs clearly contradict the definition of "global scope". This document discusses the why the terminology employed for the specification of ULAs is problematic, along with some practical consequences of the current specification of ULAs. Finally, it formally updates RFC4291 and RFC4193 such that the scope of ULAs is defined as "local". "The IPv6 Address-based DHCPv6 Unique Identifier (DUID-V6ADDR)", Fred Templin, 2021-01-11, This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-V6ADDR that contains a single 128 bit IPv6 address. DUID-V6ADDR makes it possible for devices to use suitably-derived unique IPv6 addresses to identify themselves to DHCPv6 servers and/or other network nodes. "Service Function Chaining with Stitched Tunnels", Shraddha Hegde, Colby Barth, 2021-01-07, The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.This document describes transport mechanisms that use stitched tunnels to achieve end-to-end service chaining. This document specifies two different types of transport encodings, one based on SR-MPLS and another based on IP tunnels. "The SRv6 END.DTM Segment Type", Shraddha Hegde, Kaliraj Vairavakkalai, Ron Bonica, 2021-01-08, This document describes a new SRv6 segment type, called END.DTM. The END.DTM segment type supports inter-working between SRv6 and SR-MPLS. Like any segment type, END.DTM contains a function and arguments. The function causes the processing SRv6 node to remove an SRv6 header and impose an SR-MPLS label stack. The arguments determine MPLS- label stack contents. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Faster Block Transmission", Mohamed Boucadair, Jon Shallow, 2021-01-13, 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 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. "Profiles for Traffic Engineering (TE) Topology Data Model", Italo Busi, Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Oscar de Dios, 2021-01-11, This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". "Date and Time on the Internet: Timestamps with additional information", Ujjwal Sharma, 2021-01-22, This document defines a date and time format for use in Internet protocols for representation of dates and times using the proleptic Gregorian calendar, with optional extensions representing additional information including a time zone. "YANG data model for BGP Segment Routing Extensions", krishnadeevi, Kamran Raza, Kausik Majumdar, Bruno Decraene, 2021-01-11, This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP. "DLT Gateway Crash Recovery Mechanism", Rafael Belchior, Miguel Correia, Thomas Hardjono, 2021-01-12, This memo describes crash recovery mechanisms for the Open Digital Asset Protocol (ODAP). The memo presents ODAP-2PC, a protocol assures that gateways running ODAP are crash fault-tolerant, meaning that the atomicity of asset transfers are assured even if gateways crash. This protocol includes the description of the messaging and logging flows necessary for gateways to keep track of current state, the crash-recovery protocol, and a rollback mechanism. "Generic Delivery Functions", Zhaohui Zhang, Ron Bonica, Kireeti Kompella, 2021-01-12, 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. "Considerations for Cancellation of IETF Meetings", Martin Duke, 2021-01-13, The IETF firmly believes in the value of in-person meetings to reach consensus on documents. However, various emergencies can make a planned in-person meeting impossible. This document provides criteria for making this judgment. "Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP)", Magnus Westerlund, John Mattsson, Claudio Porfiri, Michael Tuexen, 2021-01-15, This document describes a proposed update for the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document intend to obsolete RFC 6083 and removes the 16 kB limitation on user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further updates the DTLS versions to use, as well as the HMAC algorithms for SCTP-AUTH, and simplifies the implementation by some stricter requirements on the establishment procedures. "Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)", Greg Mirsky, Fabrice Theoleyre, Georgios Papadopoulos, Carlos Bernardos, 2021-01-15, 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 data flow. "Path Computation Element Protocol(PCEP) Extension for RSVP Color", Balaji Rajagopalan, Vishnu Beeram, Gyan Mishra, 2021-01-15, 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. "Multicast Path MTU", tathagata nandy, Utkarsh Srivastava, 2021-01-17, Path MTU discovery (rfc1191) is a standard technique to determine the supported MTU between two Internet Protocol (IP) hosts to avoid any fragmentation. In a multicast distribution tree, source will not know where the receivers are located. So the technique used to compute the path MTU for a unicast stream does not work in a multicast network. This document describes a method to discover multicast path MTU with the goal to avoid traffic loss. This solution also aims to solve the problem of traffic loss in for multicast streams because of incorrect MTU setting and no path MTU support for multicast networks. "Static Context Header Compression (SCHC) Architecture", Alexander Pelov, Pascal Thubert, Ana Minaburo, 2021-01-19, This document defines the SCHC architecture. "Segment Routing Header encapsulation for Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, 2021-01-19, 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 Policy for Unaffiliated BFD Echo Function", Mach Chen, Xinjun Chen, 2021-01-20, This document describes how to leverage Segment Routing (SR) Policy to make sure that the Unaffiliated BFD (U-BFD) Echo packets must be transmitted to 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 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. "Secure NEighbor Discovery (SEND) over OMNI Interfaces", Fred Templin, 2021-01-22, The Overlay Multilink Network Interface (OMNI) specification can be used by nodes on public Internetworks when a suitable security service is provided to authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages. The basic OMNI security service for transmission of IPv6 ND messages over public Internetworks uses a Hashed Message Authentication Code (HMAC) based on a shared secret. This document specifies use of the Secure NEighbor Discovery (SEND) protocol over OMNI interfaces which can provide a more flexible and robust service. "On storing CBOR encoded items on stable storage", Michael Richardson, 2021-01-21, This document proposes an on-disk format for CBOR objects that is friendly to common on-disk recognition systems like the Unix file(1) command. This document is being discussed at: https://github.com/mcr/cbor- magic-number "Enhanced JWT Claim Constraints for STIR Certificates", Russ Housley, 2021-01-21, RFC 8226 provides a certificate extension to constrain the JWT claims that can be included in the PASSporT as defined in RFC 8225. If the signer includes a JWT claim outside the constraint boundaries, then the recipient will reject the entire PASSporT. This document defines additional ways that the JWT claims can be constrained. "Identity Use Cases in Browser Catalog", Vittorio Bertocci, George Fletcher, 2021-01-22, This informational document aims to gather in a single place all the most important scenarios in which identity protocols in current use leverage web browser features to achieve their goals and deliver their intended user experience. The purpose of compiling this scenario collection is to make it easier for the identity community to engage with the browser vendors, and in particular to preserve (or enhance) user experience and expressive power of the identity protocols in mainstream use as browsers introduce new privacy preserving restrictions and new identity tailored features. By providing a single artifact, listing scenarios in a consistent format, we hope to anchor the conversation on concrete outcomes and impact of changes on end users, developers, providers and in general everyone contributing to identity in the industry. 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, 2020-07-13, 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, 2020-09-17, 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. "Port Randomization in the Network Time Protocol Version 4", Fernando Gont, Guillermo Gont, Miroslav Lichvar, 2020-09-15, The Network Time Protocol can operate in several modes. Some of these modes are based on the receipt of unsolicited packets, and therefore require the use of a well-known port as the local port number. However, in the case of NTP modes where the use of a well- known port is not required, employing such well-known port unnecessarily increases the ability of attackers to perform blind/ off-path attacks. This document formally updates RFC5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. "Roughtime", Aanchal Malhotra, Adam Langley, Watson Ladd, 2020-08-29, 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 Version 4", Neta Schiff, Danny Dolev, Tal Mizrahi, Michael Schapira, 2020-09-03, 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. "Alternative NTP port", Miroslav Lichvar, 2020-10-12, 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 in order to make NTP safe for the Internet. Network Virtualization Overlays (nvo3) -------------------------------------- "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, 2020-08-30, 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, 2020-11-15, 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, 2020-11-15, 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-01-22, 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). "BATS Coding Scheme for Multi-hop Data Transport", Shenghao Yang, Xuan Huang, Raymond Yeung, John Zao, 2020-11-16, This document describes a BATS coding scheme for communication through multi-hop networks. 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. "Coding and congestion control in transport", Nicolas Kuhn, Emmanuel Lochin, Francois Michel, Michael Welzl, 2020-10-30, Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. Using FEC coding can help deal with transfer tail losses 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. Web Authorization Protocol (oauth) ---------------------------------- "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)", Nat Sakimura, John Bradley, Michael Jones, 2020-09-10, The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. "OAuth 2.0 Security Best Current Practice", Torsten Lodderstedt, John Bradley, Andrey Labunets, Daniel Fett, 2020-10-05, This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. "JWT Response for OAuth Token Introspection", Torsten Lodderstedt, Vladimir Dzhuvinov, 2020-10-18, 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, 2020-10-02, 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. "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", Vittorio Bertocci, 2021-01-22, This specification defines a profile for issuing OAuth 2.0 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner. "OAuth 2.0 Pushed Authorization Requests", Torsten Lodderstedt, Brian Campbell, Nat Sakimura, Dave Tonge, Filip Skokan, 2020-12-14, This document defines the pushed authorization request endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. "OAuth 2.0 Rich Authorization Requests", Torsten Lodderstedt, Justin Richer, Brian Campbell, 2020-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, 2020-11-18, 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, 2020-07-30, 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 the HTTP 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 Identifier in Authorization Response", Karsten zu Selhausen, Daniel Fett, 2021-01-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. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Network Telemetry Framework", Haoyu Song, Fengwei Qin, Pedro Martinez-Julia, Laurent Ciavaglia, Aijun Wang, 2021-01-21, 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. Network telemetry, as necessitated by best industry practices, covers technologies and protocols that extend beyond conventional network Operations, Administration, and Management (OAM). The presented network telemetry framework promises better flexibility, scalability, accuracy, coverage, and performance. In addition, it facilitates the implementation of automated control loops to address both today's and tomorrow's network operational needs. This document clarifies the terminologies and classifies the modules and components of a network telemetry system from several 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. "Yang data model for TACACS+", Guangying Zheng, Zitao Wang, Bo Wu, 2020-08-29, This document defines a TACACS+ client YANG module, that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization and Accounting. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "A Layer 3 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed Boucadair, Luis Munoz, Alejandro Aguado, 2020-10-16, This document defines a L3VPN Network YANG Model (L3NM) that can be used to manage the provisioning of Layer 3 Virtual Private Network (VPN) services within a Service Provider's 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, Luay Jalil, Jichun Ma, 2020-11-02, This document defines a YANG Data model (called, L2NM) that can be used to manage the provisioning of Layer 2 VPN services within a Service Provider Network. This YANG module provides representation of the Layer 2 VPN Service from a network standpoint. The module is meant to be used by a Network Controller to derive the configuration information that will be sent to relevant network devices. The L2NM YANG Data model complements the Layer 2 Service Model (RFC8466) by providing a network-centric view of the service that is internal to a Service Provider. "A Layer 2/3 VPN Common YANG Model", samier barguil, Oscar de Dios, Mohamed Boucadair, Qin WU, 2021-01-14, 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: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: A Layer 2/3 VPN Common YANG Model"; o 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-01-17, This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. "Finding and Using Geofeed Data", Massimo Candela, Randy Bush, Warren Kumari, Russ Housley, 2021-01-19, This document describes how to find and authenticate geofeed data. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Operational Security Considerations for IPv6 Networks", Eric Vyncke, Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-11-03, Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. Some very specific places of a network such as the Internet of Things are not discussed in this document. "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", Fernando Gont, Will LIU, 2021-01-19, 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. "Impact of TLS 1.3 to Operational Network Security Practices", Nancy Cam-Winget, Eric Wang, Roman Danyliw, Roelof DuToit, 2020-10-25, Network-based security solutions are used by enterprises, the public sector, internet-service providers, and cloud-service providers to both complement and enhance host-based security solutions. As TLS is a widely deployed protocol to secure communication, these network- based security solutions must necessarily interact with it. This document describes this interaction for current operational security practices and notes the impact of TLS 1.3 on them. Open Shortest Path First IGP (ospf) ----------------------------------- "The Tunnel Encapsulations OSPF Router Information", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Luis Contreras, Luay Jalil, 2017-10-10, Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the tunnel encapsulator router needs to select a type of tunnel which is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisement (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. Path Aware Networking RG (panrg) -------------------------------- "Current Open Questions in Path Aware Networking", Brian Trammell, 2020-12-23, 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. "Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)", Spencer Dawkins, 2020-12-29, At the first meeting of the Path Aware Networking Research Group, the research group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for path-aware networking researchers. This document contains that catalog and analysis. "A Vocabulary of Path Properties", Theresa Enghardt, Cyrill Krahenbuhl, 2020-09-07, 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, 2020-08-17, 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, 2020-12-28, 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. "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Dhruv Dhody, Jonathan Hardwick, Vishnu Beeram, Jeff Tantsura, 2020-10-31, This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data. "Path Computation Element (PCE) Communication Protocol (PCEP) extension for associating Policies and Label Switched Paths (LSPs)", Stephane Litkowski, Siva Sivabalan, Jeff Tantsura, Jonathan Hardwick, Cheng Li, 2021-01-21, This document introduces a simple mechanism to associate policies to a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group. "PCEP Extension for Flow Specification", Dhruv Dhody, Adrian Farrel, Zhenbin Li, 2020-10-30, 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 XXXX defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC XXXX 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. RFC Editor Note: Please replace XXXX in the Abstract with the RFC number assigned to draft-ietf-idr-rfc5575bis when it is published. Please remove this note. "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)", Rakesh Gandhi, Colby Barth, Bin Wen, 2021-01-06, 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. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. This document defines PCEP extensions for grouping two unidirectional MPLS TE LSPs (one in each direction in the network) into an Associated Bidirectional LSP. The mechanisms defined in this document can be applied using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs, as well as when using a Stateless PCE. The procedures defined are applicable to the LSPs using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling. "PCEP Extension for Native IP Network", Aijun Wang, Boris Khasanov, Sheng Fang, Ren Tan, Chun Zhu, 2020-10-20, 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 [I-D.ietf-teas-pce-native-ip]. 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 Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou, 2021-01-22, The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled MPLS and GMPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. 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 for using the PCE as the central controller. "PCEP Extension for Flexible Grid Networks", Young Lee, Haomian Zheng, Ramon Casellas, Ricard Vilata, Daniele Ceccarelli, Francesco Lazzeri, 2020-08-27, 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, 2020-11-23, 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, 2020-10-18, 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-ID in PCE-based Networks.", Siva Sivabalan, Clarence Filsfils, Jeff Tantsura, Jonathan Hardwick, Stefano Previdi, Cheng Li, 2020-10-31, In order to provide greater scalability, network opacity, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID). It is possible to associate a BSID to RSVP-TE signaled Traffic Engineering Label Switching Path or binding Segment- ID (SID) to SR Traffic Engineering path. Such a binding label/SID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document proposes an approach for reporting binding label/SID to Path Computation Element (PCE) for supporting 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, 2020-11-01, 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-01-07, 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, as well as 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-01-22, 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-01-13, 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, 2020-12-15, The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. 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 SID (Segment Identifier) allocation and distribution. "PCEP Extension for Stateful Inter-Domain Tunnels", Olivier Dugeon, Julien Meuric, Young Lee, Daniele Ceccarelli, 2021-01-19, This document specifies how to combine a Backward Recursive or Hierarchical method with inter-domain paths in the context of stateful Path Computation Element (PCE). It relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables to operate them as end-to-end inter- domain paths without the need for a signaling session between inter- domain border routers. A new Stitching Label is defined, new Path Setup Types, a new Association Type and a new PCEP communication Protocol (PCEP) Capability are considered for that purpose. Privacy Enhancements and Assessments Research Group (pearg) ----------------------------------------------------------- "Guidelines for Performing Safe Measurement on the Internet", Iain Learmonth, Gurshabad Grover, 2020-11-16, 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-01-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. "On the Generation of Transient Numeric Identifiers", Fernando Gont, Ivan Arce, 2021-01-13, This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category, while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers, and analyzes their security and privacy properties. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. "Network-Based Website Fingerprinting", Ian Goldberg, Tao Wang, Christopher Wood, 2020-09-08, The IETF is well on its way to protecting connection metadata with protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in- progress towards encrypting the TLS SNI. However, more work is needed to protect traffic metadata, especially in the context of web traffic. In this document, we survey Website Fingerprinting attacks, which are a class