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 2020-05-25 18:09:34 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, 2019-07-08, 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 Backbone Router", Pascal Thubert, Charles Perkins, Eric Levy-Abegnoli, 2020-03-23, This document updates RFC 6775 and RFC 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called Backbone Routers. Backbone Routers are placed along the wireless edge of a Backbone, and federate multiple wireless links to form a single Multi-Link Subnet. "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk, 2019-12-14, 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. "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Pascal Thubert, Behcet Sarikaya, Mohit Sethi, Rene Struik, 2020-04-30, This document updates the 6LoWPAN Neighbor Discovery (ND) protocol defined in RFC 6775 and RFC 8505. The new extension is called Address Protected Neighbor Discovery (AP-ND) and it protects the owner of an address against address theft and impersonation attacks in a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof-of-ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation. "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. "6LoWPAN Selective Fragment Recovery", Pascal Thubert, 2020-03-23, This draft updates RFC 4944 with a protocol to forward individual fragments across a route-over mesh and recover them end-to-end, with congestion control capabilities to protect the network. "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network", Thomas Watteyne, Pascal Thubert, Carsten Bormann, 2020-03-23, This document provides generic rules to enable the forwarding of 6LoWPAN fragment over a route-over network. Forwarding fragments can improve both the end-to-end latency and reliability, and reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and virtual reassembly buffers. "Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2020-04-29, 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) ----------------------- "ICMPv6 errors for discarding packets due to processing limits", Tom Herbert, 2020-03-18, Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards. "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves, 2020-04-06, This document describes an extension that causes nodes 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 node. Additionally, it reduces the window of exposure of a node via an addresses 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-03-30, This document defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms. "IPv6 Minimum Path MTU Hop-by-Hop Option", Robert Hinden, Gorry Fairhurst, 2020-03-09, 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 recorded MTU 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-03-09, 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 host. It also updates [RFC4862] and recommends hosts to send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. The proposed change will minimize the delay and packet loss when a host initiate connections to off-link destination from a new IPv6 address. 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, 2019-10-29, 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-04-02, 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-02-06, 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, 2020-05-13, 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-03-09, 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, server authentication, 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-05-11, This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. "Key Management for OSCORE Groups in ACE", Marco Tiloca, Jiye Park, Francesca Palombini, 2020-05-11, 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. "MQTT-TLS profile of ACE", Cigdem Sengul, Anthony Kirby, Paul Fremantle, 2020-03-09, This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an 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, 2020-01-04, 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "Extensions to Automatic Certificate Management Environment for end user S/MIME certificates", Alexey Melnikov, 2020-05-02, 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-03-08, 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-05-18, 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-01-20, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2020-03-20, The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes; and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. "Application-Layer Traffic Optimization (ALTO) Cost Calendar", Sabine Randriamasy, Y. Yang, Qin WU, Deng Lingli, Nico Schwan, 2020-03-17, This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendar, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. "ALTO Performance Cost Metrics", Qin WU, Y. Yang, Dhruv Dhody, Sabine Randriamasy, Luis Contreras, 2020-05-16, Cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and is used in basic ALTO services including both the cost map service and the endpoint cost service. Different applications may use different cost metrics, but the ALTO base protocol [RFC7285] documents only one single cost metric, i.e., the generic "routingcost" metric; see Sec. 14.2 of [RFC7285]. Hence, if the ALTO client of an application wants to issue a cost map or an endpoint cost request to determine the resource provider offering better delay performance (i.e., low-delay) to the resource consumer, the base protocol does not define the cost metric to be used. ALTO cost metrics can be generic metrics and this document focuses on network performance metrics, including network delay, jitter, packet loss rate, hop count, and bandwidth. When using an ALTO performance metric, an application may need additional contextual information beyond the metric value. For example, whether the metric is an estimation based on measurements or a service-level agreement (SLA) can define the meaning of the performance metric. Hence, this document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey such information. To report an estimated value of a performance metric, the ALTO server may derive and aggregate from routing protocols with different granularity and scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end traffic management tools. These metrics may then be exposed by an ALTO server to allow applications to determine "where" to connect based on network performance criteria. "ALTO Extension: Path Vector", Kai Gao, Sabine Randriamasy, Y. Yang, J. Zhang, 2020-03-09, This document is an extension to the base Application-Layer Traffic Optimization protocol [RFC7285]. The current ALTO Cost Services allow applications to obtain cost values on an end-to-end path defined by its source and destination. The present extension provides abstracted information on particular network parts or elements traversed by a path between its source and destination. Examples of such abstracted parts are networks, data centers or links. This is useful for applications whose performance is impacted by particular network parts they traverse or by their properties. Applications having the choice among several connection paths may use this information to select paths accordingly and improve their performance. In particular, they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This document introduces a new cost type called Path Vector. A Path Vector is an array of entities that each identifies an abstracted representation of a network part and that are called Abstract Network Element (ANE). Each ANE is defined by a set of properties. ANE properties are conveyed by an ALTO information resource called "Property Map", that can be packed together with the Path Vectors in a multipart response. They can also be obtained via a separate ALTO request to a Property Map. An ALTO Property Map is an extension to the ALTO protocol, that is specified in another document entitled "Unified Properties for the ALTO Protocol" [I-D.ietf-alto-unified-props-new]. "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Y. Yang, Kevin Ma, Jon Peterson, Jingxuan Zhang, 2020-04-08, The Content Delivery Networks Interconnection (CDNI) framework [RFC6707] 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 [RFC7336] is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). [RFC8008] 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 [RFC8008]. "Unified Properties for the ALTO Protocol", Wendy Roome, Sabine Randriamasy, Y. Yang, J. Zhang, Kai Gao, 2020-03-09, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] 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 [RFC7285]. 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-03-09, 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-04-08, 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, 2020-05-07, 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 to the support for asynchronicity in various languages and operating systems. "Constrained Voucher Artifacts for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2020-01-15, 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, 2020-02-25, This document proposes a solution for information distribution in autonomic networks. Information distribution is categorized into two different modes: 1) instantaneous distribution; 2) publication for retrieval. In the former case, the information is sent, propagates and is disposed of after reception. In the latter case, information needs to be stored in the network. The capabilities to distribute information are basic and fundamental needs 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. 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, 2019-08-29, 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, 2018-11-06, 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-01-07, 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-04-23, 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. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Sending Multiple Types of Media in a Single RTP Session", Magnus Westerlund, Colin Perkins, Jonathan Lennox, 2015-12-18, This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", Magnus Westerlund, Bo Burman, Colin Perkins, Harald Alvestrand, Roni Even, 2020-02-18, The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Jonathan Lennox, Magnus Westerlund, Qin WU, Colin Perkins, 2016-03-02, RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. "RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus Flodman, Danny Hong, Jonathan Lennox, 2020-01-13, This memo describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. "RTP Control Protocol (RTCP) Feedback for Congestion Control", Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho, 2020-03-09, This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control. "RTP Payload Format for TSVCIS Codec", Victor Demjanenko, John Punaro, David Satterlee, 2020-04-10, This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters for enhancing voice quality. TSVCIS augmented speech data is processed in conjunction with its temporal matched MELP 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail. "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Sebastien Lugan, Antonin Descampe, Corentin Damman, Thomas Richter, Alexandre Willeme, 2020-04-08, 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, 2020-03-30, This memo describes an RTP payload format for the video coding standard ITU-T Recommendation [H.266] and ISO/IEC International Standard [ISO23090-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-05-20, 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. Regional regulatory requirements specify provision of real-time text in multi-party calls. RFC 4103 mixer implementations can use traditional RTP functions for source identification, but the mixer source switching performance is limited when using the default transmission with redundancy. An enhancement for RFC 4103 real-time text mixing is provided in the present specification, suitable for a centralized conference model that enables source identification and efficient source switching. The intended use is for real-time text mixers and multi-party-aware participant endpoints. The mechanism builds on use of the CSRC list in the RTP packet and an extended packet format 'text/rex'. A capability exchange is specified so that it can be verified that a participant can handle the multi-party coded real-time text stream. The capability is indicated by the media subtype "text/rex". The document updates RFC 4102[RFC4102] and RFC 4103[RFC4103] A brief description about how a mixer can format text for the case when the endpoint is not multi-party aware is also provided. 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. "RTP Stream Identifier Source Description (SDES)", Adam Roach, Suhas Nandakumar, Peter Thatcher, 2016-10-06, This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. Babel routing protocol (babel) ------------------------------ "Applicability of the Babel routing protocol", Juliusz Chroboczek, 2019-08-17, Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. "The Babel Routing Protocol", Juliusz Chroboczek, David Schinazi, 2020-02-06, Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. "Babel Information Model", Barbara Stark, Mahesh Jethanandani, 2019-10-09, 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, 2019-04-11, 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. "Babel Routing Protocol over Datagram Transport Layer Security", Antonin Decimo, David Schinazi, Juliusz Chroboczek, 2019-08-13, The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). "MAC authentication for the Babel routing protocol", Clara Do, Weronika Kolodziejak, Juliusz Chroboczek, 2019-08-16, This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. "YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark, 2020-01-07, This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. BGP Enabled ServiceS (bess) --------------------------- "Integrated Routing and Bridging in EVPN", Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan, 2019-03-05, 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, 2020-02-10, This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN 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, 2018-10-19, 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, 2019-07-08, The EVPN MAC/IP Advertisement route can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs. This document describes how the EVPN Proxy-ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. "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 NSH SFC", Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil, 2019-12-13, 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 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. "IGMP and MLD Proxy for EVPN", Ali Sajassi, Samir Thoria, Keyur Patel, John Drake, Wen Lin, 2020-04-28, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs. "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com, 2019-12-17, The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi-homing. The DF is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default DF Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the Default DF election procedures so that the above requirements can be met. "Propagation of ARP/ND Flags in EVPN", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wen Lin, 2019-07-03, An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. The information conveyed in the MAC/IP route may not be enough for the remote PE to reply to local ARP or ND requests. For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address, as this information is not carried in the MAC/IP route advertisements. Similarly, other information relevant to the IP->MAC ARP/ND entries may be needed. 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 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, 2020-03-11, 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 popular protocol mechanism for use within a data center, but 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. "Fast Recovery for EVPN DF Election", Ali Sajassi, Gaurav Badoni, Dhananjaya Rao, Patrice Brissette, John Drake, Jorge Rabadan, 2020-03-09, Ethernet Virtual Private Network (EVPN) solution [RFC7432] describes DF election procedures for multi-homing Ethernet Segments. These procedures are enhanced further in [RFC8584] by applying Highest Random Weight Algorithm for DF election in order to avoid DF status unnecessarily upon a failure. This draft makes further improvement to DF election procedures in [RFC8584] by providing two options for fast DF election upon recovery of the failed link or node associated with the multi-homing Ethernet Segment. This fast DF election is achieved independent of number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each PE in the multi-homing group. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan, 2020-03-09, EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions introduce Single-Active and All-Active for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of EVCs (e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. "Per multicast flow Designated Forwarder Election for EVPN", Ali Sajassi, mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake, 2020-05-21, [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-05-16, 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 bundle, 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. "Yang Data Model for Multicast in MPLS/BGP IP VPNs", Yisong Liu, Feng Guo, Stephane Litkowski, Xufeng Liu, Robert Kebler, Mahesh Sivakumar, 2019-12-02, This document defines a YANG data model that can be used to configure and manage multicast in MPLS/BGP IP VPNs. "EVPN Operations, Administration and Maintenance Requirements and Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald Eastlake, 2020-01-01, 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-05-25, 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 IPVPN provides inter-subnet forwarding, there is a need to specify the interworking aspects between both EVPN and IPVPN domains, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN should interwork 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-05-16, 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-01-06, 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. "SRv6 BGP based Overlay services", Gaurav Dawra, Clarence Filsfils, Robert Raszuk, Bruno Decraene, Shunwan Zhuang, Jorge Rabadan, 2020-02-28, 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". "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", Stephane Litkowski, Swadesh Agrawal, krishnaswamy ananthamurthy, Keyur Patel, 2020-02-11, Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. "Virtual Hub-and-Spoke in BGP EVPNs", Keyur Patel, Ali Sajassi, John Drake, Zhaohui Zhang, Wim Henderickx, 2020-01-26, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) applications and as the next generation virtual private LAN services in service provider (SP) applications. The use of host IP default route and host unknown MAC route within a DC is well understood in order to ensure that leaf nodes within a DC only learn and store host MAC and IP addresses for that DC. All other host MAC and IP addresses from remote DCs are learned and stored in DC GW nodes thus alleviating leaf nodes from learning host MAC and IP addresses from the remote DCs. This draft further optimizes the MAC and IP address learning at the leaf nodes such that a leaf node within a DC only needs to learn and store MAC and IP addresses associated with the sites directly connected to it. A leaf node does not need to learn and store MAC and IP addresses from any other leaf nodes thus reducing the number of learned MACs and IP addresses per EVI substantially. The modifications provided by this draft updates and extends RFC7024 for BGP EVPN Address Family. "Controller Based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk, Dante Pacella, Arkadiy Gulko, 2020-01-26, 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, 2020-05-13, 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. "EVPN multi-homing port-active load-balancing", Patrice Brissette, Ali Sajassi, Bin Wen, Eddie Leyton, Jorge Rabadan, LucAndre Burdet, Samir Thoria, 2020-02-17, The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables the establishment of a logical link-aggregation connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability, while providing different modes of sharing/balancing of traffic. EVPN standard defines EVPN based MC-LAG with single-active and all- active multi-homing load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support of port-active load-balancing mode. In the current document, port-active load-balancing mode is also referred to as per interface active/standby. "Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin, Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2020-02-20, [EVPN-AR] specifies an optimized ingress replication solution for more efficient multicast and broadcast delivery in a Network Virtualization Overlay (NVO) network for EVPN. This document extends the optimized ingress replication procedures specified in [EVPN-AR] to overcome the limitation that an AR- REPLICATOR may have. An AR-REPLICATOR may be unable to retain the source IP address or include the expected ESI label that is required for EVPN split horizon filtering when replicating the packet on behalf of its multihomed AR-LEAF. Under this circumstance, the extended procedures specified in this document allows the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN overlay network. "Fault Management for EVPN networks", Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake, 2020-05-01, 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. Binary Floor Control Protocol Bis (bfcpbis) ------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 2015-11-13, Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Gonzalo Camarillo, Tom Kristensen, Christer Holmberg, 2018-12-08, This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R, 2017-02-08, The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios. 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, 2019-12-09, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC5880. "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper Networks, Mach Chen, Peng Fan, 2020-02-27, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss. "Secure BFD Sequence Numbers", Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, Alan DeKok, 2020-02-27, This document describes a security enhancements for the BFD packet's sequence number. "BFD for VXLAN", Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Greg Mirsky, 2020-05-04, This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels used to form an overlay network. 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-03-04, 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, Juniper Networks, 2020-05-18, 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-05-21, 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-01-03, This document describes a hybrid performance measurement method for multicast service through a Bit Index Explicit Replication domain. "BIER Ping and Trace", Nagendra Nainar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Greg Mirsky, 2020-05-11, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2020-02-06, 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-05-18, 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. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER information. "BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols", Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda) Wang, Zheng Zhang, Markus Stenberg, 2020-03-06, This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 2020-04-16, 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-03-09, 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. "Use of BIER Entropy for Data Center Clos Networks", Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride, 2020-05-06, 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. "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Dirk Trossen, Akbar Rahman, Chonggang Wang, Toerless Eckert, 2020-02-04, 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 is also developing 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 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-02-06, 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-05-24, 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, Senthil Dhanaraj, Rajiv Asati, Yongqing Zhu, 2020-01-15, The BIER WG includes, in its charter, work on developing mechanisms to transport BIER natively in IPv6. This document is intended to help the WG with this effort by specifying requirements for transporting packets, with Bit Index Explicit Replication (BIER) headers, in an IPv6 environment. There will be a need to send IPv6 payloads, to multiple IPv6 destinations, using BIER. There have been several proposed solutions in this area. But there hasn't been a document which describes the problem and lists the requirements. The goal of this document is to describe the BIER IPv6 requirements, summarize the proposed solutions, and guide the working group in understanding the benefits, and drawbacks, of the various solutions and to help in the development of acceptable solutions. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore Tiruveedhula, 2020-03-11, 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-03-09, This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), intrusion detection and prevention solutions (IDS/ IPS) 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, traffic profiles and benchmarking methodology for NGFWs to start with. "Updates for the Back-to-back Frame Benchmark in RFC 2544", Alfred Morton, 2020-05-19, 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) ------------------------------- "Event Publishing Extensions to iCalendar", Michael Douglass, 2019-10-08, 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-03-07, 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. "VALARM Extensions for iCalendar", Cyrus Daboo, Ken Murchison, 2020-01-17, This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. Captive Portal Interaction (capport) ------------------------------------ "CAPPORT Architecture", Kyle Larose, David Dolson, Heng Liu, 2020-05-11, This document describes a CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution. The role of Provisioning Domains (PvDs) is described. "Captive Portal API", Tommy Pauly, Darshak Thakore, 2020-04-27, This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their Captive Portal sessions. "Captive-Portal Identification in DHCP / RA", Warren Kumari, Erik Kline, 2020-05-23, In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive-portal enforcement device, and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of authenticating to, and interacting with the captive portal are out of scope of this document. This document replaces RFC 7710. RFC 7710 used DHCP code point 160. Due to a conflict, this document specifies 114. [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ] Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Concise Binary Object Representation (CBOR)", Carsten Bormann, Paul Hoffman, 2020-03-08, The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. "Concise Binary Object Representation (CBOR) Tags for Date", Michael Jones, Anthony Nadalin, Joerg Richter, 2020-05-07, 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applicaitons needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined. 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-03-11, 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 Lopezalvarez, Daniel King, 2020-05-18, 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-03-08, 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 Lopezalvarez, Yunbin Xu, 2020-03-08, This document describes the YANG data model for OTN Tunnels. "YANG data model for Flexi-Grid Optical Networks", Universidad de Madrid, Daniel Perdices, Victor Lopezalvarez, Daniel King, Young Lee, Haomian Zheng, 2020-01-09, This document defines a YANG model for managing flexi-grid optical Networks. The model described in this document defines a flexi-grid traffic engineering database. A complementary module is referenced to detail the flexi-grid media channels. This module is grounded on other defined YANG abstract models. "A Yang Data Model for WSON Tunnel", Young Lee, Haomian Zheng, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, Ricard Vilata, 2020-03-18, This document provides a YANG data model for WSON TE tunnel. "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee, Kwang-koog Lee, Haomian Zheng, Dhruv Dhody, Oscar de Dios, Daniele Ceccarelli, 2020-03-08, This document provides a YANG data model for Layer 1 Connectivity Service Model (L1CSM). The intent of this document is to provide a Layer 1 service model exploiting YANG data model, which can be utilized by a customer network controller to initiate a service request connectivity as well as retrieving service states toward a Layer 1 network controller communicating with its customer network controller. This YANG model is NMDA-compliant. "Applicability of GMPLS for B100G Optical Transport Network", Qilei Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti, 2020-03-06, This document examines the applicability of using current existing GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link, as a result of the introduction of OTU/ODU links with rates larger than 100G in the 2016 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-05-09, 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-05-09, 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, Victor Lopezalvarez, Gabriele Galimberti, Dieter Beller, 2020-03-09, 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 Lopezalvarez, Daniel King, 2020-05-18, 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, 2020-05-05, 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-05-12, This document defines a collection of common data types and groupings in YANG data modeling language for layer 1 networks. These derived common types and groupings are intended to be imported by modules that specifies the OTN networks, including the 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 Request Routing Extensions", Ori Finkelman, Sanjay Mishra, 2019-11-20, 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). The extensions specified in this document to the CDNI Metadata Interface (MI) and the Footprint and Capabilities Interface (FCI) are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile, Sanjay Mishra, 2020-03-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, 2020-03-21, This document updates RFC 8007 to include generic extensions and more granular content matching options, required by the Open Caching architecture. The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial Content Delivery Networks (CDNs) to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of Content Delivery Networks Interconnection (CDNI), where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The extensions specified in this document to the CDNI Control Interface / Triggers are derived from requirements of Open Caching but are applicable to CDNI use cases in general. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "Extensible Binary Meta Language", Steve Lhomme, Dave Rice, Moritz Bunkus, 2020-01-27, This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. "FFV1 Video Coding Format Version 0, 1, and 3", Michael Niedermayer, Dave Rice, Jerome Martinez, 2020-04-28, 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-04-28, 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-04-17, 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-04-17, 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-04-17, 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, 2020-02-18, 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. "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2020-03-25, 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. "The Transition from Classical to Post-Quantum Cryptography", Paul Hoffman, 2019-11-25, Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible. "Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin, Dimitrios Papadopoulos, Jan Vcelak, 2020-02-11, 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 Eliptic Curves (EC). "Randomness Improvements for Security Protocols", Cas Cremers, Luke Garratt, Stanislav Smyshlyaev, Nick Sullivan, Christopher Wood, 2020-05-05, Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. The Dual_EC_DRBG random number backdoor and Debian bugs are relevant examples of this problem. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol participants to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick Sullivan, Riad Wahby, Christopher Wood, 2020-04-27, This document specifies a number of algorithms that may be used to encode or hash an arbitrary string to a point on an elliptic curve. "XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305", Scott Arciszewski, 2020-01-10, The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring. This helps for long running TLS connections. This also enables XChaCha constructions to be stateless, while retaining the same security assumptions as ChaCha. This document defines XChaCha20, which uses HChaCha20 to convert the key and part of the nonce into a subkey, which is in turn used with the remainder of the nonce with ChaCha20 to generate a pseudorandom keystream (e.g. for message encryption). This document also defines AEAD_XChaCha20_Poly1305, a variant of [RFC8439] that utilizes the XChaCha20 construction in place of ChaCha20. "Hybrid Public Key Encryption", Richard Barnes, Karthikeyan Bhargavan, Christopher Wood, 2020-05-08, 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. "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Alex Davidson, Nick Sullivan, Christopher Wood, 2020-03-09, 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-03-12, 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. "draft-irtf-cfrg-bls-signature-02", Dan Boneh, Sergey Gorbunov, Riad Wahby, Hoeteck Wee, Zhenfei Zhang, 2020-03-09, 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, 2020-04-28, Pairing-based cryptography, a variant of elliptic curve cryptography, has received attention for its flexible and applicable functionality. Pairing is a special map defined over 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 a 100-bit security level due to the effect of the attack. In this memo, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely use", we select the recommended pairing-friendly curves considering exTNFS. "The ristretto255 Group", Henry de Valence, Jack Grigg, George Tankersley, Filippo Valsorda, Isis Lovecruft, 2020-05-04, This memo specifies a prime-order group, ristretto255, 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. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 2016-01-08, This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. "Mapping RTP streams to CLUE Media Captures", Roni Even, Jonathan Lennox, 2017-02-27, This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano, 2016-08-13, This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. "CLUE Protocol data channel", Christer Holmberg, 2019-04-24, This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)", Robert Hansen, Paul Kyzivat, Lennard Xiao, Christian Groves, 2019-12-09, This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", Roberta Presta, Simon Romano, 2019-07-05, The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. Constrained RESTful Environments (core) --------------------------------------- "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann, Peter van der Stok, Christian Amsuess, 2020-03-09, In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, 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 a Resource Directory 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, 2020-03-09, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output, notifications and yang data template defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. "YANG Schema Item iDentifier (SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, 2020-03-27, YANG Schema Item iDentifiers (SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. "CoAP Management Interface", Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Ivaylo Petrov, 2020-03-09, This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. The complete solution composed of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called CORECONF. 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-03-09, 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; it is now the recommeded way to mitigate amplification attacks. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. "Group OSCORE - Secure Group Communication for CoAP", Marco Tiloca, Goeran Selander, Francesca Palombini, Jiye Park, 2020-04-06, 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. using IP multicast. In particular, the described approach defines how OSCORE should be used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and the corresponding CoAP responses. "Uniform Resource Names for Device Identifiers", Jari Arkko, Cullen Jennings, Zach Shelby, 2019-12-13, This memo 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 easily passed along in any application that needs the information. "FETCH & PATCH with Sensor Measurement Lists (SenML)", Ari Keranen, Mojan Mohajer, 2020-03-09, The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The CoAP FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the SenML data model. "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", Klaus Hartke, 2020-04-12, This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323. "Constrained YANG Module Library", Michel Veillette, Ivaylo Petrov, 2020-01-23, 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). "The Constrained RESTful Application Language (CoRAL)", Klaus Hartke, 2020-03-09, The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. "Constrained Resource Identifiers", Klaus Hartke, 2020-03-09, The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. "Additional Units for SenML", Carsten Bormann, 2020-03-19, The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry. "Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP", Ilpo Jarvinen, Markku Kojo, Iivo Raitahila, Zhen Cao, 2020-03-04, 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-03-30, 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-05-13, 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. "Problem Details For CoAP APIs", Thomas Fossati, Jaime Jimenez, Klaus Hartke, 2020-05-13, This document defines a "problem detail" as a way to carry machine- readable details of errors in a CoAP response to avoid the need to define new error response formats for CoAP APIs. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE): Structures and Process", Jim Schaad, 2020-05-14, 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-05-14, 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. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. The details of the structure of COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes RFC8152. "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Jim Schaad, 2020-03-09, The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parts of 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-03-09, 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: Indirect signatures where the hash of one or more contents are signed. 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. "COSE and JOSE Registrations for WebAuthn Algorithms", Michael Jones, 2020-05-13, The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", Mark Baushke, 2018-01-02, 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. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking (DetNet) Security Considerations", Tal Mizrahi, Ethan Grossman, 2020-03-18, A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency. As a result, securing a DetNet implies that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed whose purpose is exclusively to secure the intended operation of these novel service properties. This document addresses specifically those security considerations, with the assumption that the reader is already familiar with network security best practices for the data plane technologies underlying a given DetNet implementation. This document defines a threat model and a taxonomy of relevant attacks, including their potential impacts and mitigations. A given DetNet may require securing only certain aspects of DetNet performance, for example extremely low data loss rates but not necessarily bounded latency. Therefore this document provides an association of threats against various use cases by industry, and also against the individual service properties as defined in the DetNet Use Cases. This document also addresses common DetNet security considerations related to the IP and MPLS data plane technologies (the first to be identified as supported by DetNet), thereby complementing the Security Considerations sections of the various DetNet Data Plane (and other) DetNet documents. "DetNet Flow Information Model", Balazs Varga, Janos Farkas, Rodney Cummings, Yuanlong Jiang, Don Fedyk, 2020-05-15, 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, Zhenqiang Li, Reshad Rahman, Don Fedyk, 2020-03-09, 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 Framework", Balazs Varga, Janos Farkas, Lou Berger, Andrew Malis, Stewart Bryant, 2020-05-06, This document provides an overall framework for the DetNet data plane. It covers concepts and considerations that are generally common to any Deterministic Networking data plane specification. It describes related controller plane considerations as well. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, Don Fedyk, 2020-03-06, 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-05-06, This document specifies the MPLS Deterministic Networking data plane operation and encapsulation over an IP network. The approach is modeled on the operation of MPLS and over UDP/IP packet switched networks. "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2020-03-06, This document specifies the Deterministic Networking MPLS data plane when operating over a TSN sub-network. "DetNet Data Plane: MPLS", Balazs Varga, Janos Farkas, Lou Berger, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2020-04-23, This document specifies the Deterministic Networking data plane when operating over an MPLS Packet Switched Networks. "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2020-03-06, This document specifies the Deterministic Networking IP data plane when operating over a TSN sub-network. "DetNet Data Plane: IP over MPLS", Balazs Varga, Lou Berger, Don Fedyk, Stewart Bryant, Jouni Korhonen, 2020-05-06, This document specifies the Deterministic Networking data plane when operating in an IP over MPLS packet switched network. "DetNet Data Plane: IP", Balazs Varga, Janos Farkas, Lou Berger, Don Fedyk, Stewart Bryant, 2020-04-23, This document specifies the Deterministic Networking data plane when operating in an IP packet switched network. "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane", Greg Mirsky, Mach Chen, 2020-03-29, This document lists functional requirements for Operations, Administration, and Maintenance (OAM) toolset in Deterministic Networks (DetNet) and, using these requirements; defines format and use principals of the DetNet service Associated Channel over a DetNet network with the MPLS data plane.. Dynamic Host Configuration (dhc) -------------------------------- "Link-Layer Addresses Assignment Mechanism for DHCPv6", Bernie Volz, Tomek Mrugalski, Carlos Bernardos, 2020-05-05, In certain environments, e.g. large scale virtualization deployments, new devices are created in an automated manner. Such devices typically have their link-layer (MAC) addresses randomized. With sufficient scale, the likelihood of collision is not acceptable. Therefore an allocation mechanism is required. This draft proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments. "SLAP quadrant selection options for DHCPv6", Carlos Bernardos, Alain Mourad, 2020-05-13, The IEEE originally structured the 48-bit MAC address space in such a way that half of it was reserved for local use. Recently, the IEEE has been working on a new specification (IEEE 802c) which defines a new optional "Structured Local Address Plan" (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space. The IEEE is working on mechanisms to allocate addresses in the one of these quadrants (IEEE 802.1CQ). There is work also in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. We complement this work by defining a mechanism to allow choosing the SLAP quadrant to use in the allocation of the MAC address to the requesting device/client. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC addresses to the given client out of the quadrant requested by relay or client. A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this purpose. "DHCPv6 Extension Practices and Considerations", Ren Gang, Lin He, Ying Liu, 2020-05-11, The manageability, security, privacy protection, and traceability 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", Ian Farrer, Naveen Kottapalli, Martin Hunek, Richard Patterson, 2020-03-05, Operational experience with DHCPv6 prefix delegation has shown that when the DHCPv6 relay function is not co-located with the DHCPv6 server function, issues such as timer synchronization between the DHCP functional elements, rejection of client's messages by the relay, and other problems have been observed. These problems can result in prefix delegation failing or traffic to/from clients addressed from the delegated prefix being unrouteable. Although [RFC8415] mentions this deployment scenario, it does not provide necessary detail on how the relay element should behave when used with PD. This document describes functional requirements for a DHCPv6 PD relay when used for relaying prefixes delegated by a separate DHCPv6 server. "IPv6-Only-Preferred Option for DHCP", Lorenzo Colitti, Jen Linkova, Michael Richardson, Tomek Mrugalski, 2020-03-09, This document specifies a DHCP option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2020-03-09, In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. Dispatch (dispatch) ------------------- "ECMAScript Media Types Updates", Matthew Miller, Myles Borins, Mathias Bynens, Bradley Farias, 2020-04-22, This document updates the ECMAScript media types, replacing the existing registrations for "application/javascript" and "text/ javascript" with information and requirements aligned with implementation experiences. This document obsoletes RFC4329, "Scripting Media Types". Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Recommended Usage of the Authenticated Received Chain (ARC)", Steven Jones, Kurt Andersen, 2020-05-07, The Authenticated Received Chain (ARC) provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. But the specification does not indicate how the entities handling these messages should interpret or utilize ARC results in making decisions about message disposition. This document will provide guidance in these areas. "DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)", Scott Kitterman, 2020-03-12, 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. 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-03-08, 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. "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Carlos Bernardos, 2020-03-07, This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or re-started using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network. "Proxy Mobile IPv6 extensions for Distributed Mobility Management", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, Juan Zuniga, Alain Mourad, 2020-03-08, Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as a local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. Domain Name System Operations (dnsop) ------------------------------------- "A Common Operational Problem in DNS Servers - Failure To Communicate", Mark Andrews, Ray Bellis, 2020-04-16, The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. The document does not look at the DNS data itself, just the structure of the responses. "DNS Transport over TCP - Operational Requirements", John Kristoff, Duane Wessels, 2020-05-06, This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. This includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this best common practice is not upheld. "Extended DNS Errors", Warren Kumari, Evan Hunt, Roy Arends, Wes Hardaker, David Lawrence, 2020-05-05, This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. "Secret Key Transaction Authentication for DNS (TSIG)", Francis Dupont, Stephen Morris, Paul Vixie, Donald Eastlake, Olafur Gudmundsson, Brian Wellington, 2020-05-04, This document describes a protocol for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client, or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets: it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism. This document obsoletes RFC2845 and RFC4635. "Running a Root Server Local to a Resolver", Warren Kumari, Paul Hoffman, 2020-03-13, Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round- trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent version of the document, open issues, and so on should all be available there. The authors gratefully accept pull requests. ] "DNS Query Name Minimisation to Improve Privacy", Stephane Bortzmeyer, Ralph Dolmans, Paul Hoffman, 2020-03-09, This document describes techniques called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME 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 NOTE FOR THE DNSOP WORKING GROUP: There is still much work to be done in this draft. Future versions of this draft will contain descriptions of different minimisation implementation choices that have been made since the RFC 7816 first came out, as well as deployment experience. "Multi Signer DNSSEC models", Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak, David Blacka, 2020-04-19, Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describe these key management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key management requirements on authoritative servers not involved in multi signer configurations. "Message Digest for DNS Zones", Duane Wessels, Piet Barber, Matt Weinberg, Warren Kumari, Wes Hardaker, 2020-04-28, This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes an ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. ZONEMD is not designed to 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 at this time, ZONEMD is not designed for use in large, dynamic zones due to the time and resources required for digest calculation. The ZONEMD record described in this document is designed so that new digest schemes may be developed in the future to support large, dynamic zones. "Fragmentation Avoidance in DNS", Kazunori Fujiwara, Paul Vixie, 2020-04-12, 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. "Terminology for DNS Transports and Location", Paul Hoffman, 2020-02-11, 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. "DNS Resolver Information Self-publication", Puneet Sood, Roy Arends, Paul Hoffman, 2020-02-11, This document describes methods for DNS resolvers to self-publish information about themselves, such as whether they perform DNSSEC validation or are available over transports other than what is defined in RFC 1035. The information is returned as a JSON object. The names in this object are defined in an IANA registry that allows for light-weight registration. Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers. There is a GitHub repo for this draft where pull requests can be issued: https://github.com/DNSOP/draft-ietf-dnsop-resolver- information However, starting issues on the WG mailing list is preferred. "Interoperable Domain Name System (DNS) Server Cookies", Ondrej Sury, Willem Toorop, Donald Eastlake, Mark Andrews, 2020-05-20, DNS cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of denial-of-service and amplification, forgery, or cache poisoning attacks by off-path attackers. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. This document updates [RFC7873] "Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2020-03-09, This document specifies the "SVCB" and "HTTPSSVC" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keying material for encrypting TLS SNI). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPSSVC DNS 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 proposal is inspired by and based on recent DNS usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have SRV or a functional equivalent implemented for HTTP). These proposals each provide an important function but are potentially incompatible with each other, such as when an origin is load-balanced across multiple hosting providers (multi-CDN). Furthermore, these each add potential cases for adding additional record lookups in-addition to AAAA/A lookups. This design attempts to provide a unified framework that encompasses the key functionality of these proposals, as well as providing some extensibility for addressing similar future challenges. TO BE REMOVED: The specific name for this RR type is an open topic for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as they are easy to replace. Other names might include "B", "SRV2", "SVCHTTPS", "HTTPS", and "ALTSVC". 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. "YANG Types for DNS Classes and Resource Record Types", Ladislav Lhotka, Petr Spacek, 2020-05-15, 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 Catalog Zones", Peter van Dijk, Libor Peltan, Ondrej Sury, Willem Toorop, Leo Vandewoestijne, 2020-04-14, 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. "The DELEGATION_ONLY DNSKEY flag", Paul Wouters, Wes Hardaker, 2020-05-06, This document introduces a new DNSKEY flag called DELEGATION_ONLY that indicates that the particular zone will never sign zone data across a label. That is, every label (dot) underneath is considered a zone cut and must have its own (signed) delegation. Additionally, it indicates the zone is expecting its parent to never bypass or override the zone. DNSSEC Validating Resolvers can use this flag to mark any data that violates the DELEGATION_ONLY policy as BOGUS. "Recommendations for DNSSEC Resolvers Operators", Daniel Migault, Edward Lewis, Dan York, 2020-05-21, The DNS Security Extensions define a process for validating received data and assert them authentic and complete as opposed to forged. This document is focused clarifying the scope and responsibilities of DNSSEC Resolver Operators (DRO) as well as operational recommendations that DNSSEC validators operators SHOULD put in place in order to implement sufficient Trust that makes DNSSEC validation output accurate. The recommendations described in this document include, provisioning mechanisms as well as monitoring and management mechanisms. "DNS TIMEOUT Resource Record", Tom Pusateri, Tim Wattenberg, 2020-05-24, 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. Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- "Discovery Proxy for Multicast DNS-Based Service Discovery", Stuart Cheshire, 2019-03-24, This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. "DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2019-10-13, The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. "DNS-SD Privacy and Security Requirements", Christian Huitema, Daniel Kaiser, 2020-03-12, DNS-SD (DNS Service Discovery) normally discloses information about devices offering and requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service. 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-05-15, 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. "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Andrew Mortensen, Tirumaleswar Reddy.K, Flemming Andreasen, Nik Teague, Rich Compton, 2020-03-06, This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Tirumaleswar Reddy.K, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague, 2020-01-06, This document specifies the 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. 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 Specification"; 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) Data Channel Specification (used to be I-D.ietf-dots-data- channel) Please update TBD/TBD1/TBD2 statements with the assignments made by IANA to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG modules. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", Mohamed Boucadair, Tirumaleswar Reddy.K, 2019-07-21, The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. 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) Data Channel Specification"; o reference: RFC XXXX Please update the "revision" date of the YANG module. "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Mohamed Boucadair, Tirumaleswar Reddy.K, Wei Pan, 2020-01-22, This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide some guidance for DOTS clients/gateways when multihomed. "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery", Mohamed Boucadair, Tirumaleswar Reddy.K, 2020-02-07, It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure DOTS clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. "Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", Kaname Nishizuka, Mohamed Boucadair, Tirumaleswar Reddy.K, Takahiko Nagata, 2020-03-02, This document specifies an extension to the 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 supposed to be conveyed by a DOTS client during an idle time 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 these statements with the RFC number to be assigned to the following documents: o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be [I-D.ietf-dots-signal-channel]) o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification" (used to be [I-D.ietf-dots-data-channel]) 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, 2020-03-02, This document specifies the DOTS signal channel Call Home, which enables a DOTS server to initiate a secure connection to a DOTS client, and to receive the attack traffic information from the DOTS client. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to the home networks; the solution targets any deployment which requires 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- signal-channel) Please update TBD statements with the assignment 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-05-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. DNS PRIVate Exchange (dprive) ----------------------------- "Recommendations for DNS Privacy Service Operators", Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij, Allison Mankin, 2020-05-04, This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS Privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, and how the decisions and alternatives impact the privacy of users. This document also presents a framework to assist writers of a DNS Recursive Operator Privacy Statement (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC6841). "DNS Privacy Considerations", Stephane Bortzmeyer, Sara Dickinson, 2020-05-04, 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", Han Zhang, Pallavi Aras, Willem Toorop, Sara Dickinson, Allison Mankin, 2020-05-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 DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers. "DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers", Jason Livingood, Alexander Mayrhofer, Benno Overeinder, 2019-12-15, This document provides requirements for adding confidentiality to DNS exchanges between recursive resolvers and authoritative servers. "Using Early Data in DNS over TLS", Alessandro Ghedini, 2020-04-22, This document illustrates the risks of using TLS 1.3 early data with DNS over TLS, and specifies behaviors that can be adopted by clients and servers to reduce those risks. "Specification of DNS over Dedicated QUIC Connections", Christian Huitema, Allison Mankin, Sara Dickinson, 2020-04-27, 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-05-25, This document defines the requirements for Drone Remote Identification Protocol (DRIP) Working Group protocols to support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for safety, regulatory compliance 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 on-line and off-line verification that UAS RID information is trustworthy. "Drone Remote Identification Protocol (DRIP) Architecture", Stuart Card, Adam Wiethuechter, Robert Moskowitz, Shuai Zhao, 2020-05-18, This document defines an architecture for Drone Remote Identification Protocol (DRIP) Working Group protocols and services to support Unmanned Aircraft System Remote Identification (UAS RID) and RID- related communications, including its building blocks and their interfaces, all to be standardized. CAVEAT LECTOR: This draft version is undergoing substantial restructuring and is submitted to the DRIP WG only to spark discussion on architecture and to be adopted as a placeholder if there is consensus that there should be an architecture document (however far from any future consensus on that architecture this draft may be). Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane, 2020-05-22, 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, 2020-03-10, 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-05-15, 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. "Bundle-in-Bundle Encapsulation", Scott Burleigh, 2020-02-18, This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called "custody transfer". This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. "BPSec Interoperability Security Contexts", Edward Birrane, 2020-02-04, This document defines an integrity security context and a confidentiality security context suitable for testing the interoperability of Bundle Protocol Security (BPSec) implementations. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Non-Interactive Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens, 2020-03-09, Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. EAP Method Update (emu) ----------------------- "Using EAP-TLS with TLS 1.3", John Mattsson, Mohit Sethi, 2020-03-09, 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 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, 2020-03-09, The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary 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 replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. 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-05-22, 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-05-09, 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 the this problem in detail and describes the potential solutions available. "EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP", Alan DeKok, 2020-05-14, EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA when using the fast re-authentication exchange instead of full authentication. This document updates RFC 5247 to define those derivations for EAP-SIM and EAP-AKA. RFC 5247 also does not define Session-Id derivation for PEAP. A definition is given here which follows the definition for other TLS-based EAP methods. "Nimble out-of-band authentication for EAP (EAP-NOOB)", Tuomas Aura, Mohit Sethi, 2020-05-05, 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, speakers 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-05-14, 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, 2020-05-08, 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 RFC 6409. "IMAP4 Extension: Message Preview Generation", Michael Slusarz, 2019-12-10, This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated representation of message data useful as a contextual preview of the entire message. General Area (gen) ------------------ "Specifying the IANA Contact for Registrations in IETF Documents", Barry Leiba, 2020-04-10, IETF documents have been inconsistent in what they specify as the registrant (or contact, or change controller) in IANA registrations they make. This document provides a consistent specification ("IETF") to be used, and allows for exceptions with IESG approval. GitHub Integration and Tooling (git) ------------------------------------ "Working Group GitHub Administration", Alissa Cooper, Paul Hoffman, 2020-04-13, The use of GitHub in IETF working group processes is increasing. This document describes uses and conventions for working groups which are considering starting to use GitHub. It does not mandate any processes, and does not require changes to the processes used by current and future working groups not using GitHub. "Working Group GitHub Usage Guidance", Martin Thomson, Barbara Stark, 2020-03-19, This document provides a set of guidelines for Working Groups that choose to use GitHub for their work. Note to Readers Discussion of this document takes place on the GitHub@ietf mailing list (ietf-and-github@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search?email_list=ietf-and-github. Source for this draft and an issue tracker can be found at https://github.com/ietf-gitwg/using-github. Global Routing Operations (grow) -------------------------------- "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2020-05-08, The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In and locally originated routes (e.g. routes distributed into BGP from protocols such as static) but not access to the BGP instance Loc-RIB. This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the BGP instance Local-RIB, as defined in RFC 4271 the routes that have been selected by the local BGP speaker's Decision Process. These are the routes over all peers, locally originated, and after best-path selection. "RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering", Job Snijders, stucchi-lists@glevia.com, Melchior Aelmans, 2020-04-24, This document describes a way to define groups of Autonomous System numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide a mechanism to be used by operators for filtering BGP-4 [RFC4271] announcements. "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Alexander Azimov, 2020-01-25, Problem definition for route leaks and enumeration of types of route leaks are provided in [RFC7908]. 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-03-09, 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. 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-04-23, 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, 2020-05-21, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and 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) ------------------------- "Outsourcing Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Michael Richardson, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2020-04-19, The Homenet Naming authority is responsible for making devices within the home network accessible by name within the home network as well as from outside the home network (e.g. the Internet). The names of the devices accessible from the Internet are stored in the Public Homenet Zone, served by a DNS authoritative server. It is unlikely that home networks will contain sufficiently robust platforms designed to host a service such as the DNS on the Internet and as such would expose the home network to DDoS attacks. This document describes a mechanism that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure via a Distribution Master (DM). "DHCPv6 Options for Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Tomek Mrugalski, Chris Griffiths, Wouter Cloetens, 2020-04-19, 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-03-09, 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, =?utf-8?q?St=C3=A9phane_Couture?=, Joseph Hall, 2020-03-08, This document discuss 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 forum, it provides a global public space despite being built on predominantly private infrastructure. Since Internet protocols play a central role in the management, development and use of the Internet, the relation between protocols and the aforementioned rights should be analyzed and any adverse impacts should be mitigated. HTTP (httpbis) -------------- "HTTP Client Hints", Ilya Grigorik, Yoav Weiss, 2020-05-18, 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-04-20, 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-04-19, 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. "Secondary Certificate Authentication in HTTP/2", Mike Bishop, Nick Sullivan, Martin Thomson, 2020-05-14, A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established. The means by which these credentials are used with requests is defined. "HTTP Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 2020-03-07, 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 Messaging", Roy Fielding, Mark Nottingham, Julian Reschke, 2020-03-07, 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, 2020-03-07, The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, and portions of RFC 7230. "The Cache-Status HTTP Response Header Field", Mark Nottingham, 2020-03-01, To aid debugging, HTTP caches often append headers to a response detailing how they handled the request. This specification codifies that practice and updates it for HTTP's current caching model. "The Proxy-Status HTTP Response Header Field", Mark Nottingham, Piotr Sikora, 2020-03-01, This document defines the Proxy-Status HTTP header field to convey the details of intermediary handling of responses, including generated errors. "Digest Headers", Roberto Polli, Lucas Pardue, 2020-03-09, This document defines the Digest and Want-Digest header fields for HTTP, 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 RFC 7231. "Extensible Prioritization Scheme for HTTP", Kazuho Oku, Lucas Pardue, 2020-03-05, 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-04-10, 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) ----------------------------------------------- "Information Model of NSFs Capabilities", Liang Xia, John Strassner, Cataldo Basile, Diego Lopez, 2019-04-24, This draft defines the concept of an NSF (Network Security Function) capability, as well as its information model. Capabilities are a set of features that are available from a managed entity, and are represented as data that unambiguously characterizes an NSF. Capabilities enable management entities to determine the set of features from available NSFs that will be used, and simplify the management of NSFs. "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 Lopez, Gabriel Lopez-Millan, Fernando Pereniguez-Garcia, 2019-08-05, This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. "I2NSF Consumer-Facing Interface YANG Data Model", Jaehoon Jeong, Chaehong Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2020-03-11, 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 organized based on the "Event-Condition-Action" (ECA) policy model defined by a capability information model for I2NSF [i2nsf-capability-im], 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-05-07, 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, 2019-07-25, This document defines a 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-03-30, 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 into 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, Chaehong Chung, Susan Hares, Liang Xia, Henk Birkholz, 2020-05-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 or the potential sign of denial of service attacks 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. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: "This version of this YANG module is part of RFC 6087;" "RFC XXXX: I2NSF NSF Monitoring YANG Data Model" "reference: RFC 6087" Please update the "revision" date of the YANG module. Interface to the Routing System (i2rs) -------------------------------------- "A YANG Data Model for Layer-2 Network Topologies", Jie Dong, Xiugang Wei, Qin WU, Mohamed Boucadair, Anders Liu, 2020-03-11, This document defines a YANG data model for Layer 2 network topologies. 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 YANG Data Model for Layer-2 Network Topologies"; o reference: RFC XXXX Please update the "revision" date of the YANG module. Internet Architecture Board (iab) --------------------------------- "The "xml2rfc" version 3 Vocabulary", Heather Flanagan, 2020-03-09, This document defines the "xml2rfc" version 3 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the earlier v3 grammar described in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the xml2rfc-dev@ietf.org mailing list, which has its home page at . "The Internet is for End Users", Mark Nottingham, 2020-03-09, This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favour end users. It also explores how this can more effectively be achieved. "Report from the IAB workshop on Design Expectations vs. Deployment Reality in Protocol Development", Jari Arkko, Ted Hardie, 2020-03-09, 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, 2020-02-07, 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-02-27, 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-03-02, 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. Interactive Connectivity Establishment (ice) -------------------------------------------- "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla, Justin Uberti, Peter Saint-Andre, 2018-04-15, This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session. "Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)", Christer Holmberg, Justin Uberti, 2020-04-29, During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and updates RFC8445 and RFC XXXX by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check. [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published. Please also indicate that this specification updates RFC XXXX.] Information-Centric Networking (icnrg) -------------------------------------- "Research Directions for Using ICN in Disaster Scenarios", Jan Seedorf, Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2020-01-30, Information Centric Networking (ICN) is a new paradigm where the network provides users with named content, instead of communication channels between hosts. This document outlines some research directions for Information Centric Networking with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking Research Group (ICNRG). "Information-Centric Networking (ICN): CCNx and NDN Terminology", Bastiaan Wissingh, Christopher Wood, Alex Afanasyev, Lixia Zhang, David Oran, Christian Tschudin, 2020-01-17, Information Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG). "Native Deployment of ICN in LTE, 4G Mobile Networks", Prakash suthar, Milan Stolic, Anil Jangam, Dirk Trossen, Ravi Ravindran, 2020-05-07, LTE, 4G mobile networks use IP-based transport for control plane to establish the data session and user plane for actual data delivery. In existing architecture, IP transport used in the user plane is not optimized for data transport, which leads to an inefficient data delivery. IP unicast routing from server to clients is used for delivery of multimedia content to User Equipment (UE), where each user gets a separate stream. From a bandwidth and routing perspective, this approach is inefficient. Multicast and broadcast technologies have emerged recently for mobile networks, but their deployments are very limited or at an experimental stage due to complex architecture and radio spectrum issues. ICN is a rapidly emerging technology with built-in features for efficient multimedia data delivery. However 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 an inherent capability for multicast, anchorless mobility and security, and it is 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 (along with IP). These approaches can help optimize the mobile networks by leveraging the inherent benefits of ICN. 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-03-22, 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. "Architectural Considerations of ICN using Name Resolution Service", Jungha Hong, Taewan You, Ved Kafle, 2020-03-09, This document discusses architectural considerations and implications of Information-Centric Networking (ICN) related to the usage of the Name Resolution Service (NRS). It describes how ICN architectures may change and what implications are introduced within the ICN routing system when NRS is integrated into an ICN architecture. "ICN Adaptation to LoWPAN Networks (ICN LoWPAN)", Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin, 2020-05-01, 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 link 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). "Internet Protocol Tunneling over Content Centric Mobile Networks", Greg White, Susmit Shannigrahi, Chengyu Fan, 2020-01-31, This document describes a protocol that enables tunneling of Internet Protocol traffic over a Content Centric Network (CCNx) or a Named Data Network (NDN). The target use case for such a protocol is to provide an IP mobility plane for mobile networks that might otherwise use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) used by the Evolved Packet Core in LTE networks (LTE-EPC). By leveraging the elegant, built-in support for mobility provided by CCNx or NDN, this protocol achieves performance on par with LTE-EPC, equivalent efficiency, and substantially lower implementation and protocol complexity [Shannigrahi]. Furthermore, the use of CCNx/NDN for this purpose paves the way for the deployment of ICN native applications on the mobile network. "Considerations in the development of a QoS Architecture for CCNx-like ICN protocols", David Oran, 2020-02-28, 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 as a resource in addition to memory, CPU and link bandwidth 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, 2020-02-04, 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 from 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-03-19, This document presents the design of an ICN Ping protocol. It includes the operations both on the client and the forwarder side. "ICN Traceroute Protocol Specification", Spyridon Mastorakis, Jim Gibson, Ilya Moiseenko, Ralph Droms, David Oran, 2020-03-19, This document presents the design of an ICN Traceroute protocol. This includes the operations both on the client and the forwarder side. Inter-Domain Routing (idr) -------------------------- "Dissemination of Flow Specification Rules for IPv6", Christoph Loibl, Robert Raszuk, Susan Hares, 2020-04-20, Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [I-D.ietf-idr-rfc5575bis] specifies those extensions for IPv4 protocol data packets only. This specification extends [I-D.ietf-idr-rfc5575bis] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Kevin Wang, 2020-01-08, This document proposes a solution for BGP route reflectors to allow them to choose the best path for their clients that the clients themselves would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. 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 a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per peer. Best path selection can also be performed based on user configured policies in each route reflector. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra, 2020-03-08, This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] 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. "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, 2020-04-27, This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald Eastlake, Stephane Litkowski, Shunwan Zhuang, 2020-05-24, 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-05-17, Administrative groups (commonly referred to as "colors" or "link colors") are link attributes that are advertised by link state protocols like IS-IS (Intermediate System to Intermediate System) and OSPF (Open Shortest Path First) and used for traffic engineering. These administrative groups have initially been defined as a fixed- length 32-bit bitmask. As networks grew and more use-cases were introduced, the 32-bit length was found to be constraining and hence extended administrative groups were introduced in the link state protocols. The 32-bit administrative groups are already advertised as link attributes in BGP-LS (Border Gateway Protocol Link-State). This document defines extensions to BGP-LS for advertisement of the extended administrative groups. "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. "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas, 2020-02-26, 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 Ramachandra, 2019-12-01, RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2020-04-12, 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. "Dissemination of Flow Specification Rules", Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson, Martin Bacher, 2020-05-20, This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (e.g. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. "Route Leak Prevention using Roles in Update and Open messages", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Kotikalapudi Sriram, 2020-05-15, Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP 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 BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an OTC attribute according to the agreed relationship, allowing both prevention and detection of route leaks. "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State", Jeff Tantsura, Uma Chunduri, Ketan Talaulikar, Greg Mirsky, Nikos Triantafillis, 2020-05-08, This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. "Extended BGP Administrative Shutdown Communication", Job Snijders, Jakob Heitz, John Scudder, Alexander Azimov, 2020-04-15, This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. "BGP-LS Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo Chen, Ketan Talaulikar, Shunwan Zhuang, 2020-04-01, 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. "Revision to Capability Codes Registration Procedures", John Scudder, 2020-05-08, This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Reserved for Private Use" is divided into three new ranges, respectively designated as "First Come First Served", "Experimental Use" and "Reserved". "BGP Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Bruno Decraene, 2020-01-07, Segment Routing 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, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. 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-05-18, 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 which 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-01-06, 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-05-06, 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-03-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-03-05, 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-05-07, 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. "BGP Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang Ou, Yujia Luo, Sujian Lu, Huaimo Chen, Shunwan Zhuang, Haibo Wang, 2020-05-16, It is hard to adjust traffic and optimize traffic paths on a traditional IP network from time to time through manual configurations. It is desirable to have an automatic mechanism for setting up routing policies, which adjust traffic and optimize 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-05-21, 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 policies 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-04-28, Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate 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. Internet Area (int) ------------------- "Guidelines and Registration Procedures for Interface Types and Tunnel Types", Dave Thaler, Dan Romascanu, 2020-01-16, This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANA Considerations sections and YANG modules, and so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863, and provides updated guidance for these registries. 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. "Discovering Provisioning Domain Names and Data", Pierre Pfister, Eric Vyncke, Tommy Pauly, David Schinazi, Wenqin Shao, 2020-01-31, Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. This allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider. This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to additional PvD information that can be retrieved using HTTP over TLS. "IP Fragmentation Considered Fragile", Ron Bonica, Fred Baker, Geoff Huston, Robert Hinden, Ole Troan, Fernando Gont, 2019-09-30, This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. 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, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David Mozes, Petr Lapukhov, remy@barefootnetworks.com, daniel.bernier@bell.ca, Jennifer Lemon, 2020-03-09, 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. "Advanced Unidirectional Route Assessment (AURA)", Jose Alvarez-Hamelin, Alfred Morton, Joachim Fabini, Carlos Pignataro, Ruediger Geib, 2019-12-11, 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. "Multipoint Alternate Marking method for passive and hybrid performance monitoring", Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo Sisto, 2020-03-23, The Alternate Marking method, as presented in RFC 8321, can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. "Simple Two-way Active Measurement Protocol Optional Extensions", Greg Mirsky, Xiao Min, Henrik Nydell, Richard Foote, Adi Masputra, Ernesto Ruffini, 2020-03-23, This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) which enable measurement performance metrics in addition to ones supported by the STAMP base specification. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762. "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, 2020-03-09, 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-01-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 IP Capacity", Alfred Morton, Ruediger Geib, Len Ciavattone, 2020-03-09, This memo revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. "In-situ OAM Direct Exporting", Haoyu Song, Barak Gafni, Tianran Zhou, Zhenbin Li, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Tal Mizrahi, 2020-02-06, 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. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Mixing Preshared Keys in IKEv2 for Post-quantum Security", Scott Fluhrer, Panos Kampanakis, David McGrew, Valery Smyslov, 2020-01-14, The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer, by using preshared keys. "IKEv2 Notification Status Types for IPv4/IPv6 Coexistence", Mohamed Boucadair, 2019-10-21, This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. "Intermediate Exchange in the IKEv2 Protocol", Valery Smyslov, 2019-12-16, 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 Traffic Flow Security", Christian Hopps, 2020-03-02, 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. "Group Key Management using IKEv2", Brian Weis, Valery Smyslov, 2020-01-08, This document presents a set of IKEv2 exchanges that comprise a group key management protocol. 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, grbartle@cisco.com, Scott Fluhrer, Daniel Van Geest, Oscar Garcia-Morchon, Valery Smyslov, 2020-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 of 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 tranform 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-03-09, This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, it makes a problem statement about key aspects in IPv6-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document specifies requirements for IPv6-based vehicular networking. JSON Mail Access Protocol (jmap) -------------------------------- "Handling Message Disposition Notification with JMAP", Raphael Ouazana, 2020-04-30, This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. "A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket", Ken Murchison, 2020-03-19, This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2020-03-09, This document specifies a data model for synchronizing calendar data with a server using JMAP. "S/MIME signature verification extension to JMAP", Alexey Melnikov, 2020-02-10, This document specifies an extension to JMAP for returning S/MIME signature verification status. "JMAP for Quotas", Rene Cordier, Michael Bailly, 2020-03-03, This document specifies a data model for handling quotas on accounts with a server using JMAP. "JSContact: A JSON representation of contact data", Robert Stepanek, Mario Loffredo, 2020-02-10, 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. 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-05-20, 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 relying on FAST. 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. "A Simple Anonymous GSS-API Mechanism", Luke Howard, 2020-05-05, This document defines protocols, procedures and conventions for a Generic Security Service Application Program Interface (GSS-API) security mechanism that provides key agreement without authentication of either party. "Best practices for password hashing and storage", Sam Whited, 2020-05-20, This document outlines best practices for handling user passwords and other authenticator secrets in client-server systems making use of SASL. Lightweight Authenticated Key Exchange (lake) --------------------------------------------- "Requirements for a Lightweight AKE for OSCORE", Malisa Vucinic, Goeran Selander, John Mattsson, Dan Garcia-Carillo, 2020-04-29, This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. This draft is in a working group last call (WGLC) in the LAKE working group. Post-WGLC, the requirements will be considered sufficiently stable for the working group to proceed with its work. It is not currently planned to publish this draft as an RFC. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1", Michael Richardson, Thomas Werner, Wei Pan, 2020-05-06, This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that was presented. "Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information", Tadahiko Ito, Sean Turner, 2020-03-31, This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. "Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection", Russ Housley, 2020-03-09, This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers are adequately protected. "CMP Updates", Hendrik Brockhaus, 2020-03-04, This document contains a set of updates to the base syntax of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue and the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities. "Lightweight CMP Profile", Hendrik Brockhaus, Steffen Fries, David von Oheimb, 2020-03-04, 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 uses 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 also in more complex scenarios, other types of operations are specified as recommended or optional. "OCSP Nonce Extension", Mohit Sahni, 2020-05-15, This document specifies the updated format of the Nonce extension in Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate and the Nonce extension is used in the OCSP request and response messages to avoid replay attacks. This document updates the RFC 6960 Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2020-01-13, 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-03-11, 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-03-05, 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-01-09, 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, their implementation and operational complexity reduces 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-04-09, 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-03-01, 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 L2/L3 EID Mobility Using a Unified Control Plane", Marc Portoles-Comeras, Vrushali Ashtaputre, Victor Moreno, Fabio Maino, Dino Farinacci, 2020-05-21, 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-05-07, 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-04-09, 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-04-02, 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-01-08, This document describes extentions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation. "Publish/Subscribe Functionality for LISP", Alberto Rodriguez-Natal, Vina Ermagan, Johnson Leong, Fabio Maino, Albert Cabellos-Aparicio, Sharon Barkai, Dino Farinacci, Mohamed Boucadair, Christian Jacquenet, Stefano Secci, 2020-03-18, 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-02-13, 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-03-19, This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. "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-05-03, This document specifies use of H3 and LISP to reflect status of public roads: - Enabling tile by tile, indexed annotation of streets & curbs in real time - Sharing: hazards, blockages, parking, weather, maintenance, inventory.. - Between MobilityClients who produce and consume geo-state information - Using geo-spatial IP channels for the 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, 2020-03-05, This draft defines the way SCHC (Static Context Header Compression) header compression can be applied to the CoAP protocol. SCHC is a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the redundancy and the size of the information in the header. While [I-D.ietf-lpwan-ipv6-static-context-hc] describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies the use of 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 how to apply 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-04-17, The Static Context Header Compression (SCHC) specification describes generic header compression and fragmentation techniques for LPWAN (Low Power Wide Area Networks) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies. This document provides the adaptation of SCHC for use in LoRaWAN networks, and provides elements such as efficient parameterization and modes of operation. This is called a profile. "Data Model for Static Context Header Compression (SCHC)", Ana Minaburo, Laurent Toutain, 2020-02-28, This document describes a YANG data model for the SCHC (Static Context Header Compression) compression and fragmentation rules. "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Laurent Toutain, 2020-05-16, The Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification describes both, an application header compression scheme, and a frame fragmentation and loss recovery functionality for Low Power Wide Area Network (LPWAN) technologies. SCHC offers a great level of flexibility that can be tailored for different 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, 2020-05-17, 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-04-17, 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 tunnel. 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. "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-04-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 tunnel. 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. "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2020-02-05, 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, 2020-01-09, This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing. "IS-IS TE Attributes per application", Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx, John Drake, 2020-05-18, Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Traffic Engineering, Loop Free Alternate) have been defined which also make use of the link attribute advertisements. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements which address both of these shortcomings. "OSPF Link Traffic Engineering Attribute Reuse", Peter Psenak, Les Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake, 2020-05-19, Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Traffic Engineering, Loop Free Alternate) have been defined which also make use of the link attribute advertisements. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 which address both of these shortcomings. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2020-04-01, 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 enforce 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. "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Les Ginsberg, Huaimo Chen, Tony Przygienda, Dave Cooper, Luay Jalil, Srinath Dontula, 2020-05-17, 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 Extension", Aijun Wang, Acee Lindem, Jie Dong, Peter Psenak, Ketan Talaulikar, 2019-11-24, This document defines Open Shortest Path First (OSPF) encodings to advertise the router-id of the originator of inter-area prefixes for OSPFv2 and OSPFv3 Link-State Advertisements (LSAs). The source originator is needed in several multi-area OSPF use cases. "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu, 2020-04-23, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. "Invalid TLV Handling in IS-IS", Les Ginsberg, Paul Wells, Tony Li, Tony Przygienda, Shraddha Hegde, 2020-01-15, Key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type/Length/Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV which is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to insure that interoperability is maximized. This document when approved updates RFC3563, RFC5305, RFC6232, and RFC6233. "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Yingzhen Qu, 2020-04-24, 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-04-24, This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisment (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, 2020-01-08, 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-01-06, This document specifies the extensions to OSPF that enables a router and its neighbor to signal their intention to use Bidirectional Forwarding Detection (BFD) for their adjacency using link-local advertisement between them. The signaling of this BFD enablement, allows the router to block and not allow the establishment of adjacency with its neighbor router until a BFD session is successfully established between them. The document describes this OSPF "strict-mode" of BFD establishment as a prerequisite to adjacency formation. "OSPF Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston, 2020-01-06, 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, 2020-01-22, 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-02-12, 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). Link State Vector Routing (lsvr) -------------------------------- "Shortest Path Routing Extensions for BGP Protocol", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2020-05-15, 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-03-24, 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-05-25, 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, 2019-11-04, This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic 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-03-09, 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. "Virtual reassembly buffers in 6LoWPAN", Carsten Bormann, Thomas Watteyne, 2020-03-09, When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it. This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature. The present document attempts to fill that gap. "Alternative Elliptic Curve Representations", Rene Struik, 2020-04-23, 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. MBONE Deployment (mboned) ------------------------- "Multicast in the Data Center Overview", Mike McBride, Olufemi Komolafe, 2020-02-04, The volume and importance of one-to-many traffic patterns in data centers is likely to increase significantly in the future. Reasons for this increase are discussed and then attention is paid to the manner in which this traffic pattern may be judiciously handled in data centers. The intuitive solution of deploying conventional IP multicast within data centers is explored and evaluated. Thereafter, a number of emerging innovative approaches are described before a number of recommendations are made. "Multicast Considerations over IEEE 802 Wireless Media", Charles Perkins, Mike McBride, Dorothy Stanley, Warren Kumari, Juan Zuniga, 2019-12-11, 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-03-07, 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. "Deprecating ASM for Interdomain Multicast", Mikael Abrahamsson, Tim Chown, Leonard Giuliano, Toerless Eckert, 2020-03-09, This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organisation or domain and are especially easy to adopt in existing intradomain ASM/PIM-SM deployments. "Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, 2020-03-11, This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. "Discovery Of Restconf Metadata for Source-specific multicast", Jake Holland, 2020-03-11, This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. "Circuit Breaker Assisted Congestion Control", Jake Holland, 2020-03-11, This document specifies Circuit Breaker Assisted Congestion Control (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate metadata about multicast channels from senders to intermediate network nodes or receivers. The circuit breaker behavior is defined as a supplement to receiver driven congestion control systems, to preserve network health if receivers subscribe to a volume of traffic that exceeds capacity policies or capability for a network or receiver. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "JSON binding of IODEF", Takeshi Takahashi, Roman Danyliw, Mio Suzuki, 2020-03-01, The Incident Object Description Exchange Format defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This draft gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in CBOR. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert, 2020-03-06, 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-01-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 with from two to a large number of clients. It is meant to protect against eavesdropping, tampering, and message forgery. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", Ali Begen, Paul Kyzivat, Colin Perkins, Mark Handley, 2019-08-09, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", Christer Holmberg, Roman Shpount, Salvatore Loreto, Gonzalo Camarillo, 2017-04-20, The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2018-12-14, This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification updates RFC 3264, to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected. This specification updates RFC 5888, to also allow an SDP 'group' attribute to contain an identification-tag that identifies a "m=" section with the port set to zero. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that can be used to correlate bundled RTP/RTCP packets with their appropriate "m=" section. This specification updates RFC 7941, by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension. "WebRTC MediaStream Identification in the Session Description Protocol", Harald Alvestrand, 2018-12-13, This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", Marc Petit-Huguenin, Suhas Nandakumar, Christer Holmberg, Ari Keranen, Roman Shpount, 2019-08-13, This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar, 2018-02-28, The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", Emil Ivov, Thomas Stach, Enrico Marocco, Christer Holmberg, 2018-06-23, The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new SDP 'end-of- candidates' attribute and a new SIP Option Tag 'trickle-ice' are defined. "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2019-03-05, In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. "SDP-based Data Channel Negotiation", Keith Drage, Maridi Makaraju, Richard Ejzak, Jerome Marcon, Roni Even, 2019-05-11, Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or using some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. "MSRP over Data Channels", Jose Recio, Christer Holmberg, 2020-05-04, This document specifies how the Message Session Relay Protocol (MSRP) can be transported as a WebRTC data channel sub-protocol, using the SDP offer/answer generic data channel negotiation framework to establish such a channel. Two network configurations are supported: connecting two MSRP over data channel endpoints; and a gateway configuration, connecting an MSRP over data channel endpoint with an MSRP over TCP or TLS endpoint. "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", Christer Holmberg, Roman Shpount, 2017-10-29, This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122. "RTP Payload Format Restrictions", Adam Roach, 2018-05-15, In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", Christer Holmberg, 2017-05-05, This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. "Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP)", Martin Thomson, Eric Rescorla, 2019-08-09, This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be mislead about the identity of a communicating peer. Mitigation techniques are defined that implementations of RFC 8122 are encouraged to deploy. "T.140 Real-time Text Conversation over WebRTC Data Channels", Christer Holmberg, Gunnar Hellstrom, 2020-04-10, This document specifies how a WebRTC data channel can be used as a transport mechanism for Real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140), and how the SDP offer/answer mechanism can be used to negotiate such data channel, referred to as T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels. Media OPerationS (mops) ----------------------- "Operational Considerations for Streaming Media", Jake Holland, Ali Begen, Spencer Dawkins, 2020-03-09, 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", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2019-12-19, 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, 2019-10-23, 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 Base", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, 2020-03-04, This document contains a specification of the MPLS base YANG model. The MPLS base YANG model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS-enabled router. It is expected that other MPLS YANG models (e.g. MPLS Label Switched Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS base YANG model. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2020-04-20, 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, 2019-09-03, 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, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Greg Mirsky, Giuseppe Fioccola, 2020-04-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. "Synonymous Flow Label Framework", Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Greg Mirsky, 2019-10-09, RFC 8372 describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called Synonymous Flow Labels in which labels which mimic the behaviour of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router. "RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon, Tarek Saad, Rakesh Gandhi, Abhishek Deshmukh, Markus Jork, Vishnu Beeram, 2020-02-26, This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) Traffic-Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute (FRR), and subsequently, improves scalability when undergoing FRR convergence after a link or node failure. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them. "LDP Extensions for RMR", Santosh Esale, Kireeti Kompella, 2020-03-09, This document describes LDP extensions to signal Resilient MPLS Ring (RMR) Label Switched Paths (LSPs). An RMR LSP is a multipoint to point LSP signaled using LDP (Label Distribution Protocol). RMR Architecture document - draft-ietf-mpls-rmr-02 - describes why and how MPLS should be used in ring topologies. "Special Purpose Label terminology", Loa Andersson, Kireeti Kompella, Adrian Farrel, 2020-05-05, This document discusses and recommends a terminology that may be used when MPLS Special Purpose Labels (SPL) are specified and documented. This document updates RFC 7274 and RFC 3032. "Updating the IANA MPLS LSP Ping Parameters", Loa Andersson, Mach Chen, Carlos Pignataro, Tarek Saad, 2020-04-16, This document updates RFC 8029 and RFC 8611 that both define IANA registries for MPLS LSP Ping. It also updates the language that is used to define the procedures for responses are sent when an unkwon or errored code point is found. The updates are for clarification and to align this name space with recent developments. "OSPFv3 CodePoint for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro, Mustapha Aissaoui, 2020-05-07, 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. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu, 2020-05-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: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "RESTCONF Client and Server Models", Kent Watsen, 2020-05-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): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server o "HHHH" --> the assigned RFC value for draft-ietf-netconf-netconf- client-server o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, Gary Wu, 2020-05-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: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "NETCONF Client and Server Models", Kent Watsen, 2020-05-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): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "A YANG Data Model for a Keystore", Kent Watsen, 2020-05-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. 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: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "Common YANG Data Types for Cryptography", Kent Watsen, 2020-05-20, This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. 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: o "AAAA" --> 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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "A YANG Data Model for a Truststore", Kent Watsen, 2020-05-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: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "YANG Modules for describing System Capabilities and Yang-Push Notification Capabilities", Balazs Lengyel, Alexander Clemm, Benoit Claise, 2020-03-23, This document defines two YANG modules: The module ietf-system-capabilities provides a structure that can be used to specify YANG related system capabilities for servers. The module can be used in conjunction with YANG Instance Data to make this information available at implementation-time. The module can also be used to report capability information from the server at run- time. The module ietf-notification-capabilities augments ietf-system- capabilities to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael Scharf, 2020-05-20, This document defines three YANG modules: the first defines a grouping for configuring a generic TCP client, the second defines a grouping for configuring a generic TCP server, and the third defines a grouping common to the TCP clients and TCP servers. 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: o "DDDD" --> 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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) "An HTTPS-based Transport for Configured Subscriptions", Mahesh Jethanandani, Kent Watsen, 2020-03-09, 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-05-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): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "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: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) 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. "YANG Data Structure Extensions", Andy Bierman, Martin Bjorklund, Kent Watsen, 2019-12-09, This document describes YANG mechanisms for defining abstract data structures with YANG. "YANG Module Tags", Christian Hopps, Lou Berger, Dean Bogdanovic, 2020-02-29, This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be registered and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC8407. "Handling Long Lines in Inclusions in Internet-Drafts and RFCs", Kent Watsen, Erik Auerswald, Adrian Farrel, Qin WU, 2020-01-20, This document defines two strategies for handling long lines in width-bounded text content. One strategy is based on the historical use of a single backslash ('\') character to indicate where line- folding has occurred, with the continuation occurring with the first non-space (' ') character on the next line. The second strategy extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. "YANG Instance Data File Format", Balazs Lengyel, Benoit Claise, 2020-04-14, There is a need to document data defined in YANG models when a live server is unavailable. Data is often needed at design or implementation time or needed when a live running server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. "YANG Module Versioning Requirements", Joe Clarke, 2019-12-30, 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-03-02, 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 the Earth or any other astronomical object. "A YANG Data Model for Factory Default Settings", Qin WU, Balazs Lengyel, Ye Niu, 2020-04-25, This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Updated YANG Module Revision Handling", Benoit Claise, Joe Clarke, Reshad Rahman, Robert Wilton, Balazs Lengyel, Jason Sterne, Kevin D'Souza, 2020-03-17, This document specifies a new YANG module update procedure that can document when non-backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with an earliest revision filter to better represent inter-module dependencies. It provides help and guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 8407 and RFC 8525. "YANG Packages", Robert Wilton, Reshad Rahman, Joe Clarke, Jason Sterne, Wu Bo, 2020-03-17, 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 documents, and can be used to define the schema associated with YANG instance data documents. "YANG Semantic Versioning", Benoit Claise, Joe Clarke, Reshad Rahman, Robert Wilton, Balazs Lengyel, Jason Sterne, Kevin D'Souza, 2020-03-17, This document specifies a scheme for applying a modified set of semantic versioning rules to revisions of YANG modules. Additionally, this document defines a revision label for this modified semver scheme based on the specification in draft-verdt- netmod-yang-module-versioning. "YANG Schema Selection", Robert Wilton, Reshad Rahman, Joe Clarke, Jason Sterne, Wu Bo, 2020-03-17, This document defines a mechanism to allow clients, using NETCONF or RESTCONF, to configure and select YANG schema for interactions with a server. This functionality can help servers support clients using older revisions of YANG modules even if later revisions contain non- backwards-compatible changes. It can also be used to allow clients to select between YANG schema defined by different organizations. This draft provides a solution to YANG versioning requirements 3.1 and 3.2. "YANG Schema Comparison", Robert Wilton, 2020-03-17, 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-03-19, 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. "Representing Netconf Data Models using Document Schema Definition Languages (DSDL)", Rohan Mahy, Sharon Chisholm, Ladislav Lhotka, 2020-03-19, This document describes a concrete approach for representing Netconf and other IETF data models using the RelaxNG schema language and the Schematron validation language, which are both part of ISO's Document Schema Definition Languages (DSDL) standard. Internet Video Codec (netvc) ---------------------------- "Video Codec Testing and Quality Measurement", Thomas Daede, Andrey Norkin, Ilya Brailovskiy, 2020-01-31, This document describes guidelines and procedures for evaluating a video codec. This covers subjective and objective tests, test conditions, and materials used for the test. Network File System Version 4 (nfsv4) ------------------------------------- "Integrity Measurement for Network File System version 4", Chuck Lever, 2020-04-03, This document specifies an OPTIONAL extension to NFS version 4 minor version 2 that enables Linux Integrity Measurement Architecture metadata (IMA) to be conveyed between NFS version 4.2 servers and clients. Integrity measurement authenticates the creator of a file's content and helps guarantee the content's integrity end-to-end from creation to use. "RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1", Chuck Lever, 2020-02-21, This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over- RDMA version 1 peers as part of establishing a connection. The addition of the private data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166. "Towards Remote Procedure Call Encryption By Default", Trond Myklebust, Chuck Lever, 2020-04-30, This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of in-transit Remote Procedure Call (RPC) transactions while interoperating with ONC RPC implementations that do not support this mechanism. This document updates RFC 5531. "Network File System (NFS) Version 4 Minor Version 1 Protocol", David Noveck, Chuck Lever, 2020-01-28, 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 RFC5661. It substantialy revises the treatment of features relating to multi-server namesapce superseding the description of those features appearing in RFC5661. "RPC-over-RDMA Version 2 Protocol", Chuck Lever, David Noveck, 2020-01-17, 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-02-03, This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 2. Network Management (nmrg) ------------------------- "Intent Classification", Chen Li, Olga Havel, Will LIU, Adriana Olariu, Pedro Martinez-Julia, Jeferson Nobre, Diego Lopez, 2020-04-21, 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 lifecycle. Up to now, there is no commonly agreed definition, interface or model of intent. This document discusses what intent means to different stakeholders, describes different ways to classify intent, and an associated taxonomy of this classification. This is a foundation for discussion intent related topics. "Intent-Based Networking - Concepts and Definitions", Alexander Clemm, Laurent Ciavaglia, Lisandro Granville, Jeff Tantsura, 2020-03-09, 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. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2019-12-20, 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: [http://NMAH/]ark:[/]NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (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-03-13, 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. "EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 2019-12-15, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "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. "Apple's DNS Long-Lived Queries protocol", Stuart Cheshire, Marc Krochmal, 2019-08-22, Apple's DNS Long-Lived Queries protocol (LLQ) is a protocol for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2019, the LLQ protocol was superseded by the IETF Standards Track RFC xxxx [[RFC Editor note: Please replace xxxx with RFC number]] "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement. The existing LLQ protocol deployed and used from 2005 to 2019 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2020-03-13, 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-03-13, 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-03-13, 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-03-13, 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-03-13, 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-03-13, 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-03-13, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2018-06-06, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the Internet Engineering Task Force (IETF) for identifying, naming, assigning, and managing persistent resources in the legal domain. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 2010-03-23, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen, 2020-01-23, The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. "Clarification of Proper Use of "@" (at sign) in URI-style Components", Robert Simpson, 2010-07-30, Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14, This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2020-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, 2020-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-03-13, 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-03-13, This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010", Stephen Slevinski, Valerie Sutton, 2011-01-03, For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "The Quality for Service Protocol", Jose Aranda, Monica Cortes, Joaquin Salvachua, Tecnalia Innovation, Inaki Sarriegui, 2019-07-05, This memo describes an application level protocol for the communication of end-to-end QoS compliance information based on the Hypertext Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service Protocol (Q4S) provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet, and to alert whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this document, it is application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile). This protocol specification is the product of research conducted over a number of years, and is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, 2020-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, 2020-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-05-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-04-30, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina Tsou, Simon Perreault, Jing Huang, 2013-09-16, An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. "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, 2019-12-09, 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. "A Format for Self-published IP Geolocation Feeds", Erik Kline, Krzysztof Duleba, Zoltan Szamonek, Stefan Moser, Warren Kumari, 2020-02-07, This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. "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. "Topology-Transparent Zone", Huaimo Chen, Alvaro Retana, Renwei Li, Ning So, Vic liu, Mehmet Toy, Lei Liu, 2020-03-09, 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 pseudo node or zone edges mess. 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 Lozano, Eduardo Alvarez, 2020-03-26, This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties in order 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. "Dynamic Service Negotiation", Mohamed Boucadair, Christian Jacquenet, Dacheng Zhang, Panos Georgatsos, 2020-03-24, This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is designed to facilitate the dynamic negotiation of service parameters. CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc. "HTTP Link Hints", Mark Nottingham, 2020-03-03, This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. "QoS-level aware Transmission Protocol (QTP) for virtual networks", Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan, 2020-03-20, 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-04-27, 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. "DNSWL Email Authentication Method Extension", Alessandro Vesely, 2020-04-30, This document describes an additional Email Authentication Method compliant with RFC 8601. The method consists in looking up the sender's IP address in a DNS whitelist. This document is provided for information in case the method is seen in the field, as well as to suggest a useful practice and register the relevant keywords. This document does not consider black lists. "RFCTool User Guide", Phillip Hallam-Baker, 2019-12-31, RFCTool is a documentation tool for building specifications from multiple sources and multiple source formats. Source formats currently supported are OOXML/Word, Markdown, XML2RFC and SVG. Publication formats supported are plaintext, HTML and XML2RFC. This document provides information on how to use RFCTool to generate Internet Drafts and RFCs. "Remote APDU Call Secure (RACS)", Pascal Urien, 2019-12-15, This document describes the Remote APDU Call Protocol Secure (RACS) protocol, dedicated to Grid of Secure Elements (GoSE). These servers host Secure Elements (SE), i.e. tamper resistant chips offering secure storage and cryptographic resources. Secure Elements are microcontrollers whose chip area is about 25mm2; they deliver trusted computing services in constrained environments. RACS supports commands for GoSE inventory and data exchange with secure elements. It is designed according to the representational State Transfer (REST) architecture. RACS resources are identified by dedicated URIs. An HTTP interface is also supported. An open implementation [OPENRACS] is available (https://github.com/purien) for various OS. "Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol", Nicholas Wilson, 2013-10-07, The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. "Metadata Query Protocol", Ian Young, 2020-01-16, This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. "Ideas for a Next Generation of the Reliable Server Pooling Framework", Thomas Dreibholz, 2020-03-13, This document collects some idea for a next generation of the Reliable Server Pooling framework. "Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen, Autumn Liu, Mehmet Toy, Vic liu, 2020-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, 2019-11-23, This draft describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a simplistic manner. Fat-tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. "SAML Profile for the Metadata Query Protocol", Ian Young, 2020-01-16, 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.13. "An Authorization Information Format (AIF) for ACE", Carsten Bormann, 2020-02-24, Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated, leading to protocol proposals such as [I-D.ietf-ace-dtls-authorize] or [I-D.ietf-ace-oscore-profile]. One potential work item complementing this protocol work is an Authorization Information Format (AIF). This document provides a strawman for such a format that should enable further discussion of the objectives for its development. "Scalable-Group Tag eXchange Protocol (SXP)", Michael Smith, Rakesh Kandula, Syam Appala, 2020-05-24, This document discusses scalable-group tag exchange protocol (SXP), a control protocol to propagate IP address to Scalable Group Tag (SGT) binding information across network devices. "BGP Auto Discovery", Robert Raszuk, Jon Mitchell, Warren Kumari, Keyur Patel, John Scudder, 2019-12-11, This document describes a method for automating portions of a router's BGP configuration via discovery of BGP peers with which to establish further sessions from an initial "bootstrap" router. This method can apply for establishment of either Internal or External BGP peering sessions. "Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", Xian Zhang, Haomian Zheng, Oscar de Dios, Victor Lopezalvarez, Yunbin Xu, 2020-04-21, 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. "Security Mechanism Names for Media", Peter Dawes, 2019-11-26, Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms. "Just because it's an ID doesn't mean anything... at all...", Warren Kumari, 2020-02-04, Anyone can publish an Internet Draft. This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Michael Richardson, 2020-03-27, 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. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, Reji Thomas, 2020-03-07, 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-03-13, 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-03-20, 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. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2020-01-02, 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 corrrects 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. "Tetrys, an On-the-Fly Network Coding protocol", Jonathan Detchart, Emmanuel Lochin, Jerome Lacan, Vincent Roca, 2020-02-27, 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 a RTT- independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications. "A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow, Siva Sivabalan, 2020-01-03, In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow labels (SFL) was introduced. This document describes a control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. "Simple Certificate Enrolment Protocol", Peter Gutmann, 2020-03-27, This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. "Multiple Upstream Interface Support for IGMP/MLD Proxy", Hitoshi Asaeda, Luis Contreras, 2020-03-10, This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface is selected based on the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described. "MPTCP Experiences in the NorNet Testbed", Thomas Dreibholz, Simone Ferlin, ozgu@simula.no, Ahmed Elmokashfi, Ioana Livadariu, Xing Zhou, 2019-12-03, This document collects some experiences of Multi-Path TCP (MPTCP) evaluations in the NorNet testbed. "Encapsulating IP in UDP", Xiaohu Xu, Hamid Assarpour, Shaowen Ma, daniel.bernier@bell.ca, Darren Dukes, Shraddha Hegde, Yiu Lee, Fan Yongbing, 2019-12-13, 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 and DTLS Security Modules", Pascal Urien, 2019-12-15, Security and trust are very critical topics in the context of the anywhere, anytime, anything internet connectivity. TLS and DTLS are two major IETF protocols widely used to secure IP exchanges. According to CoAP, DTLS is the protocol used by constraint nodes in the Internet of Things (IoT) context. In this draft we specify an ISO7816 interface for TLS and DTLS secure modules based on ISO7816 secure chips, which are today manufactured per billions every year. Secure elements are cheap secure microcontrollers whose size is about 25mm2 and whose security is ranked by evaluations typically according to Common Criteria (CC) standards. The support of TLS and DTLS is based on the EAP-TLS protocol, and the IETF draft "EAP Support in smartcard" describing EAP-TLS support for secure elements. First implementation demonstrates that such low cost security modules are realistic, with a setup time for handshake completion under the second. "LISP support for Multi-Tuple EIDs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci, 2020-04-12, This document describes extensions for LISP to support EIDs based on tuples of multiple elements. "SMTP Service Extension for Client Identity", William Storey, 2019-12-09, 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. "Asynchronous Management Protocol", Edward Birrane, 2020-04-15, This document describes a binary encoding of the Asynchronous Management Model (AMM) and a protocol for the exchange of these encoded items over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management on resource constrained devices. "Annotated Example SDP for WebRTC", Suhas Nandakumar, Cullen Jennings, 2020-05-09, The Web Real Time Communications (WebRTC) family of protocols defines mechanisms for direct interactive rich communication using audio, video and data between two peers' web browsers. Within 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. "PCEP extensions for Distribution of Link-State and TE Information", Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, 2020-03-09, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state (LS) routing protocol supporting 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-04-12, This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers to send SMR messages. This extension is intended to be used in some SDN deployments that use LISP as a southbound protocol with (P)ITRs that are compliant with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do not come from ETRs, but rather from a centralized controller that pushes the updates directly to the Mapping System. In such deployments, Map Servers will benefit from having a mechanism to inform directly (P)ITRs about updates in the mappings they are serving. Although implementations of this extension exist, this extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being documented for informational purposes. Newer implementations should look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP deployments. "Quantum Relief with TLS and Kerberos", Rick van Rein, Tom Vrancken, 2020-01-21, This specification describes a mechanism to use Kerberos authentication within the TLS protocol. This gives users of TLS a strong alternative to classic PKI-based authentication, and at the same introduces a way to insert entropy into TLS' key schedule such that the resulting protocol becomes resistant against attacks from quantum computers. We call this Quantum Relief, and specify it as part of a more general framework to make it easier for other technologies to achieve similar benefits. "Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan, Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2020-03-20, 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-01-15, 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-05-18, Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [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, 2019-12-02, 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, 2019-12-02, 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, 2020-01-15, 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-05-02, 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, 2020-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-03-05, 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-04-20, The RWA problem can be formulated as a Mixed-Integer linear program. Load balancing is a key factor for the optical transport networks. However, the existed approaches using mixed-Integer linear program to solve the RWA problem are not perfect enough without considering the load balancing of the networks. This documentary provides a model of Mixed-Integer Linear Programming to solve the problem of load balancing needed by routing and wavelength assignment (RWA) process in optical transport networks. "Mathematical Mesh 3.0 Part I: Architecture Guide", Phillip Hallam-Baker, 2020-03-09, The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that makes computers easier to use by making them more secure. The Mesh provides a set of protocol and cryptographic building blocks that enable encrypted data stored in the cloud to be accessed, managed and exchanged between users with the same or better ease of use than traditional approaches which leave the data vulnerable to attack. 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. "Special Use Domain Name 'ipv4only.arpa'", Stuart Cheshire, David Schinazi, 2020-03-19, The specification for how a client discovers its local network's NAT64 prefix (RFC7050) defines the special name 'ipv4only.arpa' for this purpose, but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties that would require special handling, and does not request IANA to record the name in the Special-Use Domain Names registry. Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. This document describes the special treatment required, formally declares the special properties of the name, adds similar declarations for the corresponding reverse mapping names, and updates RFC7050. "Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira, 2019-12-02, 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, 2019-12-02, 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, 2019-12-02, 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, 2019-12-02, 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, 2019-12-02, 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, 2019-12-02, This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. "Publishing Organization Boundaries in the DNS", John Levine, 2020-04-10, 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. "RDMA Extensions for Enhanced Memory Placement", Tom Talpey, Tony Hurson, Gaurav Agarwal, Tom Reu, 2020-03-09, This document specifies extensions to RDMA (Remote Direct Memory Access) protocols to provide capabilities in support of enhanced remotely-directed data placement on persistent memory-addressable devices. The extensions include new operations supporting remote commitment to persistence of remotely-managed buffers, which can provide enhanced guarantees and improve performance for low-latency storage applications. In addition to, and in support of these, extensions to local behaviors are described, which may be used to guide implementation, and to ease adoption. This document updates RFC5040 (Remote Direct Memory Access Protocol (RDMAP)) and updates RFC7306 (RDMA Protocol Extensions). "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira, 2019-12-02, 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, 2020-01-11, 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 pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). RFC 7470 defines a facility to carry vendor-specific information in PCEP. This document extends this capability for the stateful PCE messages. "A YANG model to manage the optical parameters for in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel, 2020-03-13, 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. "Secure IoT Bootstrapping: A Survey", Mohit Sethi, Behcet Sarikaya, Dan Garcia-Carillo, 2020-03-09, This draft provides an overview of the various terms that are used when discussing bootstrapping of 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 smart objects. "LISP Distinguished Name Encoding", Dino Farinacci, 2020-03-06, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2020-04-09, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira, 2019-12-02, 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. "SSH Agent Protocol", Damien Miller, 2019-12-10, This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. "Problem Statement Regarding IP Address Usage", Fernando Gont, Guillermo Gont, Christian Huitema, 2020-03-09, This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type), and identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. "Hybrid Hierarchical Multi-Domain Service Function chaining", Guanglei Li, Guanwen Li, Qi Xu, Hua-chun Zhou, Bohao Feng, 2020-03-26, This document describes a Hybrid Hierarchical Multi-Domain Service Function Chaining (hhSFC) architecture that extends Service Function Chaining (SFC) to multiple domains with different technology, administration or ownership. The goals of Hybrid Hierarchical SFC are to reduce the complexity of the control plane in a multi-domain scene and make the negotiation between different domains possible. "OpenPGP Message Format", Werner Koch, brian carlson, Ronald Tse, Derek Atkins, Daniel Gillmor, 2020-03-10, { 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, 2020-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, 2020-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, 2020-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. "ALTO Extension: Flow-based Cost Query", J. Zhang, Kai Gao, Junzhuo Wang, Y. Yang, 2020-03-16, ALTO cost maps and endpoint cost services map a source-destination pair into a cost value. However, current filter specifications, which define the set of source-destination pairs in an ALTO query, have two limitations: 1) Only very limited address types are supported (IPv4 and IPv6), which is not sufficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only defines filters enumerating all sources and all destinations, leading to redundant information in the response; 3) Cannot distinguish transmission types of flows in the query, which makes the server hard to respond the accurate resource consumption. To address these three issues, this document extends the base ALTO protocol with a more fine-grained filter type which allows ALTO clients to select only the concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses. "Flow Classification in Information Centric Networking", Ilya Moiseenko, David Oran, 2020-01-20, 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-03-09, 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. "Fast HIP Host Mobility", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-04-03, This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. "Guidelines for Autonomic Service Agents", Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre, 2020-01-09, 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. "Compact Format of IKEv2 Payloads", Valery Smyslov, 2020-03-31, 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-01-22, This document describes the MISP core format used to exchange indicators and threat information between MISP (Malware Information and threat 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-01-11, 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 Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 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 on a LSP to only a single PCE, and only one PCE is responsible for path computation for this delegated LSP. The document does not state the procedures related to an inter-PCE stateful communication. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE sessions 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-05-09, 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). "Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez, 2020-03-09, The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. "BIER in BABEL", Zheng Zhang, Tony Przygienda, 2020-05-17, 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, Dacheng Zhang, Liang Xia, 2020-03-11, 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 interconnect WAN 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 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-01-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-03-11, 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-05-17, 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. "Thing-to-Thing Data Hub", Klaus Hartke, 2020-05-09, A "Thing-to-Thing Data Hub" is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communications to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location. "ALTO Contextual Cost Values", Sabine Randriamasy, 2020-03-09, The Application-Layer Traffic Optimization (ALTO) Service has defined network and cost maps to provide basic network information, where the cost maps allow only one JSON value for a requested metric. This document introduces several protocol extensions to allow ALTO clients to support use cases such as context based connection selection in cellular networks and calendaring for unattended data. This document refers to other extension proposals posted in the ALTO WG that can support the present use cases as well. Likewise, some of the proposed extensions may serve other ALTO use cases. "Adaptive IPv4 Address Space", Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe, 2019-12-01, 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 the IoT (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. EzIP will immediately resolve local IPv4 address shortages, 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 and to provide the availability levels required for delivering a long-term general service. "Mobility Capability Negotiation and Protocol Selection", Zhiwei Yan, Guanggang Geng, Jong-Hyouk Lee, Tao Huang, 2020-03-23, 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. "BGP Neighbor Discovery", Xiaohu Xu, Ketan Talaulikar, Kunyang Bi, Jeff Tantsura, Nikos Triantafillis, 2019-11-26, BGP is being used as the underlay routing protocol in some large- scaled data centers (DCs). Most popular design followed is to do hop-by-hop external BGP (EBGP) session configurations between neighboring routers on a per link basis. The provisioning of BGP neighbors in routers across such a DC brings its own operational complexity. This document introduces a BGP neighbor discovery mechanism that greatly simplifies BGP operations in such DC and other networks by automatic setup of BGP sessions between neighbor routers using this mechanism. "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue, Richard Bradbury, Sam Hurst, 2020-02-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-04-03, 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". "User-Plane Protocols for Multiple Access Management Service", Jing Zhu, SungHoon Seo, Satish Kanugovi, Shuping Peng, 2020-03-04, Today, a device can be simultaneously connected to multiple communication networks based on different technology implementations and network architectures like WiFi, LTE, and DSL. In such multi- connectivity scenario, it is desirable to combine multiple access networks or select the best one to improve quality of experience for a user and improve overall network utilization and efficiency. This document presents the u-plane protocols for a multi access management services (MAMS) framework that can be used to flexibly select the combination of uplink and downlink access and core network paths having the optimal performance, and user plane treatment for improving network utilization and efficiency and enhanced quality of experience for user applications. "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, Zhong Xiang, Sandra Cespedes, 2020-05-07, 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. Also, 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-05-07, 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-03-06, 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, 2020-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, 2020-01-06, This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links. "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", Carsten Bormann, Ben Gamari, Henk Birkholz, 2020-03-09, 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC3339 time) and tag 1 (Posix time [TIME_T], int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, and anticipates the definition of related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined. "Registries for Web Authentication (WebAuthn)", Jeff Hodges, Giridhar Mandyam, Michael Jones, 2020-05-22, This specification defines IANA registries for W3C Web Authentication attestation statement format identifiers and extension identifiers. "Deployments With Insertion of IPv6 Segment Routing Headers", Daniel Voyer, Clarence Filsfils, Darren Dukes, Satoru Matsushima, John Leddy, Zhenbin Li, Jim Guichard, 2020-05-19, 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. "The 'payto' URI scheme for payments", Florian Dold, Christian Grothoff, 2020-05-01, This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments. A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. "NEAT Sockets API", Thomas Dreibholz, 2020-01-23, This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. "Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks", Zhiwei Yan, Jian Weng, Guanggang Geng, Jong-Hyouk Lee, Jaehoon Jeong, 2020-05-17, 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, 2019-12-20, 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, 2020-04-17, 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-04-01, 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). "Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, Jiang Wenying, 2020-04-26, Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path Ping to bootstrap a BFD session, control an SR Policy in the reverse direction of the SR-MPLS tunnel, and applicability of BFD Demand mode in the SR-MPLS domain. Also, the document describes the use of BFD Echo with BFD Control packet payload. "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak, 2020-01-14, 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. "Service Redundancy using BFD", Sami Boutros, Ankur Dubey, Reshad Rahman, 2020-01-24, In a data center, when multiple routing/service nodes are providing single active redundancy for a set of L2, L3 and/or L4-L7 services. Both non-revertive and revertive fail over modes are required for the services. This draft describes a method to achieve the non-revertive and revertive fail over modes for services using Bidirectional Forwarding Detection (BFD). "Responder Initiated IP Addresses Update in MOBIKE", Valery Smyslov, 2019-11-27, 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]. "A Message Header to Identify Subscription Form Mail", John Levine, 2019-11-26, Many organizations have web forms that provoke an e-mail confirmation to the e-mail address provided in the form. Malicious entities do bulk form submissions with forged addresses, resulting in mail floods to the holders of those addresses. This document defines a message header to identify mail sent in response to web forms, so that recipient mail systems can better recognize and mitigate the mail floods. "BFD in Demand Mode over Point-to-Point MPLS LSP", Greg Mirsky, 2019-12-22, 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. "SFC OAM for path consistency", Ting Ao, Greg Mirsky, Zhonghua Chen, Kent Leung, 2019-12-01, Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC 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 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", Ting Ao, Greg Mirsky, Zhonghua Chen, 2019-12-01, 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-03-09, 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. "ALTO cellular addresses", Sabine Randriamasy, 2020-03-09, This draft proposes to use the cellular address format composed of elements as specified by 3GPP and called ECGI. ECGI stands for E-UTRAN Cell Global Identifier and is used in Public Land Mobile Networks based on E-UTRAN. "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu, 2019-12-12, 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. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of SR-LSPs", Quintin Zhao, Zhenbin Li, Mahendra Negi, Shuping Peng, Chao Zhou, 2020-03-09, 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/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the path while leveraging the existing PCE technologies as much as possible. 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, in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network. "QUIC Interdomain Troubleshooting", Stephan Emile, Mathilde Cayla, Arnaud Braud, Frederic Fieau, Alexandre Ferrieux, Marcus Ihlar, 2020-01-09, On-path network performance measurements methods currently deployed contribute to the ossification of the Internet because they are expensive to deploy and to maintain. This draft motivates the exposure of QUIC header fields for on-path network measurements and their specification in the QUIC core protocol as a solution to avoid on-path network performance measurements to ossify the IP stack in the future. "L3 Aliasing and Mass Withdrawal Support for EVPN", Ali Sajassi, Gaurav Badoni, Priyanka Warade, S. Pasupula, John Drake, Jorge Rabadan, 2020-03-09, This document proposes an extension to do Aliasing and Backup paths for EVPN layer-3 routes in an IP-VRF. The solution leverages the use of EVPN Ethernet Segments for an efficient layer-3 load-balancing and fast convergence in case of failures. "ALTSVC Frame in HTTP/QUIC", Mike Bishop, 2020-05-15, [RFC7838] defines the ALTSVC frame for HTTP/2 [RFC7540]. This frame is equally applicable to HTTP/QUIC ([I-D.ietf-quic-http]), but needs to be separately registered. This document describes the ALTSVC frame for HTTP/QUIC. "Problem Statement and Considerations for ROAs issued with Multiple Prefixes", Zhiwei Yan, Randy Bush, Guanggang Geng, Jiankang Yao, 2020-03-29, 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. "Linkset: Media Types and a Link Relation Type for Link Sets", Erik Wilde, Herbert Van de Sompel, 2020-05-01, 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. "IPv6-only Terminology Definition", Jordi Palet, 2020-03-09, This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri, 2020-03-12, This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network. "HTTP Authentication with SASL", Rick van Rein, 2020-03-04, Most application-level protocols standardise their authentication exchanges under the SASL framework. HTTP has taken another course, and often ends up replicating the work to allow individual mechanisms. This specification adopts full SASL authentication into HTTP. "Reassignment of System Ports to the IESG", Mirja Kuehlewind, Sabrina Tanamal, 2020-02-10, In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate. "Guide for building an ECC pki", Robert Moskowitz, Henk Birkholz, Liang Xia, Michael Richardson, 2020-02-14, 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. "Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)", Brian Carpenter, Sheng Jiang, Bing Liu, 2020-01-09, This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP). Although not an equivalent of a file transfer protocol, such a technique may be used for non-urgent transfer of data too large to fit into a normal GRASP message. "IPv6 Source Routing for ultralow Latency", Andreas Foglar, Mike Parker, Theodoros Rokkas, 2020-01-20, 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. "Simple Group Keying Protocol (SGKP)", Donald Eastlake, Dacheng Zhang, 2020-01-15, 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. "Interconnecting (or Stitching) Network Slice Subnets", Xavier de Foy, Akbar Rahman, A. Galis, Kiran Makhijani, Li Qiang, Shunsuke Homma, Pedro Martinez-Julia, 2020-03-08, This document defines the network slice (NS) subnet as a general management plane concept that augments a baseline YANG network slice model with management attributes and operations enabling interconnections (or stitching) between network slices. The description of NS subnet interconnections is technology agnostic, and is not tied to a particular implementation of the interconnection in data plane. "Elliptic curve 2y^2=x^3+x over field size 8^91+5", Daniel Brown, 2020-04-03, Multi-curve elliptic curve cryptography with 2y^2=x^3+x/GF(8^91+5) hedges a risk of new curve-specific attacks. The curve features: isomorphism to Miller's curve from 1985; low Kolmogorov complexity (little room for embedded weaknesses of Gordon, Young--Yung, or Teske); prime field; Montgomery ladder or Edwards unified arithmetic (Hisil--Carter--Dawson--Wong); complex multiplication by i (Gallant--Lambert--Vanstone); 34-byte keys; five 64-bit-word field arithmetic; easy reduction, inversion, Legendre symbol, and square root; similarity to a Bitcoin curve; and string-as-point encoding. "A YANG Data Model for Client-layer Tunnel", Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2020-02-19, 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. "BIER BFD", Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, 2020-04-29, Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. "BIER in IPv6 (BIERin6)", Zheng Zhang, Tony Przygienda, IJsbrand Wijnands, Hooman Bidgoli, Mike McBride, 2020-01-08, BIER is a new architecture for the forwarding of multicast data packets. This document defines native IPv6 encapsulation for BIER hop-by-hop forwarding or BIERin6 for short. "Echo Request/Reply for Enabled In-situ OAM Capabilities", Xiao Min, Greg Mirsky, Lei Bo, 2020-04-29, 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. "DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR)", Dmytro Shytyi, Alexandre Petrescu, 2020-05-20, This document provides a description of the implementation of Dynamic Host Configuration Protocol version 6 Prefix Delegation, Neighbour Discovery Protocol and of the use of the Packet Data Protocol in an Internet of Things Router. This Internet of Things Router is connected on a cellular network; it is a DHCPv6-PD Client and it requests a /56 pool of prefixes from the server; the DHCPv6-PD server is placed in the PGW and is a part of the cellular infrastructure. After the pool of prefixes is delegated, the Internet of Things Router derives sub-prefixes from the prefix pool; each one of these sub-prefixes is aimed at one ingress interface. After the Internet of Things Router finishes the network prefix assignment procedure, it advertises the network prefixes on the ingress links by using the Neighbour Discovery protocol. Finally, when Hosts receive the sub-prefixes via Router Adverticement messages, they configure the Global Unique Address with the Stateless Address Auto-configuration protocol. "YANG Model for QoS Operational Parameters", Aseem Choudhary, Ing-Wher Chen, 2020-05-02, This document describes a YANG model for Quality of Service (QoS) operational parameters. "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, 2020-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-01-08, 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-04-30, This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 10 of this protocol. "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed Data Analytics", Qiao Xiang, Jensen Zhang, Franck Le, Y. Yang, Harvey Newman, 2020-03-09, As the data volume increases exponentially over time, data analytics is transiting from a single-domain network to a multi-domain, geo- distributed network, where different member networks contribute various resources, e.g., computation, storage and networking resources, to collaboratively collect, share and analyze extremely large amounts of data. Such a network calls for a resource orchestration framework that emphasizes the performance predictability of data analytics jobs, the high utilization of resources, and the autonomy and privacy of member networks. This document presents the design of Unicorn, a unified resource orchestration framework for multi-domain, geo-distributed data analytics, which uses the Application-Layer Traffic Optimization (ALTO) protocol as the key component for (1) allows member networks to provide accurate information on different types of resources; (2) keeps the private information of member networks; and (3) allows data analytics jobs to accurately describe their requirements of different types of resources. As a part of Unicorn, an ALTO extension for privacy-preserving interdomain information aggregation is also presented. "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin Cantrell, 2020-03-18, 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, 2019-12-31, This document proposes a service health check response format for HTTP APIs. "BIER Prefix Redistribute", Zheng Zhang, Wu Bo, Zhaohui Zhang, IJsbrand Wijnands, Yisong Liu, 2020-02-21, 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. "Deterministic Networking Application in Ring Topologies", Yuanlong Jiang, Norman Finn, Jeong-dong Ryoo, Balazs Varga, Liang Geng, 2020-01-07, Deterministic Networking (DetNet) provides a capability to carry data flows for real-time applications with extremely low data loss rates and bounded latency. This document describes how DetNet can be used in ring topologies to support Point-to-Point (P2P) and Point-to- Multipoint (P2MP) real-time services. "A feature freezer for the Concise Data Definition Language (CDDL)", Carsten Bormann, 2020-03-09, In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610. It is now time to discuss thawing some of the concepts discussed here. A number of additional proposals have been added. "impl-info: A link relation type for disclosing implementation information", Carsten Bormann, 2020-03-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, 2020-01-19, 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). "LURK Extension version 1 for (D)TLS 1.2 Authentication", Daniel Migault, Ioana Boureanu, 2020-01-02, This document describes the LURK Extension 'tls12' which enables interactions between a LURK Client and a LURK Server in a context of authentication with (D)TLS 1.2. "IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2020-01-18, 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. "IANA Registration of Trustword Lists: Guide, Template and IANA Considerations", Bernie Hoeneisen, Hernani Marques, 2020-01-09, This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English), which hexadecimal strings are mapped to. Such a mapping makes verification processes like fingerprint comparisons more practical, and less prone to misunderstandings. "Information-centric Routing for Opportunistic Wireless Networks", Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Carlos Borrego, 2020-03-14, This draft describes the Data reAchaBility BasEd Routing (DABBER) protocol, which aims to extend the operation of distributed Information Centric Networking frameworks to opportunistic wireless networks such as Delay Tolerant 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 and Data packets in a store-carry-and-forward manner, based on a combination of proactive and reactive approaches. The document presents an architectural overview of DABBER followed by the specification of the proactive approach based on the dissemination of name-prefix information, and the reactive approach based on the encounters probability. "Unified Identifier in IPv6 Segment Routing Networks", Weiqiang Cheng, Greg Mirsky, Shaofu Peng, Liu Aihua, XiaoLan Wan, Cheng Wei, 2020-03-14, 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, 2020-04-14, 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-04-30, 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-01-10, 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. The introduction of relaxation in this document updates RFC8231. "Hierarchy of IP Controllers (HIC)", Zhenbin Li, Dhruv Dhody, Huaimo Chen, 2020-03-08, 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, Smyshliaeva Ekaterina, 2020-03-18, 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-04-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 typical Identity-based signature algorithm, the ECCSI signature algorithm defined in RFC 6507, is supported in the current version. "Shared Brotli Compressed Data Format", Jyrki Alakuijala, Thai Duong, Evgenii Kliuchnikov, Robert Obryk, Zoltan Szabadka, Lode Vandevenne, 2020-02-11, 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-03-12, 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. "Coding for QUIC", Ian Swett, Marie-Jose Montpetit, Vincent Roca, Francois Michel, 2020-03-09, This document focuses on the integration of FEC coding in the QUIC transport protocol, in order to recover from packet losses. This document does not specify any FEC code but defines mechanisms to negotiate and integrate FEC Schemes in QUIC. By using proactive loss recovery, it is expected to improve QUIC performance in sessions impacted by packet losses. More precisely it is expected to improve QUIC performance with real-time sessions (since FEC coding makes packet loss recovery insensitive to the round trip time), with short sessions (since FEC coding can help recovering from tail losses more rapidely than through retransmissions), with multicast sessions (since the same repair packet can recover several different losses at several receivers), and with multipath sessions (since repair packets add diversity and flexibility). "Segment Routing for Resource Guaranteed Virtual Networks", Jie Dong, Stewart Bryant, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, 2020-03-09, This document describes the mechanism to associate Segment Routing Identifiers (SIDs) with network resource attributes. The resource- aware SIDs retain their original functionality, with the additional semantics of identifying the set of network resources available for the packet processing action. These SIDs can be used to build SR paths with reserved network resources. In addition, these SID can also be used to build SR based virtual networks, which provide the network topology and resource attributes required by particular services. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). "A YANG Data Model for In-Situ OAM", Tianran Zhou, Jim Guichard, Frank Brockners, Srihari Raghavan, 2020-03-05, 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. "Geneve encapsulation for In-situ OAM Data", Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey Spiegel, 2020-05-13, 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 Node", Jie Dong, Shunwan Zhuang, Gunter Van de Velde, 2020-03-09, BGP [RFC4271] has been used to distribute different types of routing and policy information in the network. In some cases, the information distributed may be only intended for one or several particular receiving BGP nodes in the network. However, BGP does not have a general mechanism of designating the receiving node 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. "ALTO-based Broker-assisted Multi-domain Orchestration", Danny Perez, Christian Rothenberg, 2020-03-09, Evolving networking scenarios (e.g., 5G) demand new multiple administrative domain (aka multi-domain) orchestration models. This document proposes a new broker-plane approach working on top of per- domain management and orchestration functions to coordinate the delivery of a multi-operator End-to-End Network Service (E2ENS). This proposed design resorts to the Application-Layer Traffic Optimization (ALTO) protocol to offer topology and resource information from different administrative domains. The ALTO services with the proposed protocol extension offer aggregated views on various types of resources contributing to a more simple and scalable solution. "EVPN All Active Usage Enhancement", Donald Eastlake, Zhenbin Li, Haibo Wang, 2020-01-15, 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-05-15, 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 Coninck, Olivier Bonaventure, 2020-03-05, This document specifies extensions to the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. The proposed extensions remain compliant with the current single-path QUIC design and preserve the QUIC privacy features. "TLS/DTLS 1.3 Profiles for the Internet of Things", Hannes Tschofenig, Thomas Fossati, 2020-04-22, This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile. "Registry for Country-Specific Secure Telephone Identity (STIR) Trust Anchors", Eric Burger, 2020-03-08, National policy defines telephone numbering governance. One area of such governance are the policies applied to the Secure Telephone Identity Credentials defined in RFC 8226. Nations have policies for the acceptable trust anchors for these credentials. This document defines an IANA registry that enables a SIP call recipient in one country to validate the signature, as defined in RFC 8224, that originates in another country useing an appropriate trust anchor for the signer's certification path, per the origination country's trust anchor policy. "Service Function discovery in fog environments", Carlos Bernardos, Alain Mourad, 2020-03-11, 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, 2020-04-27, 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-05-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-03-09, This document specifies public-key certificate enrollment procedures protected with 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. "Traffic Accounting in Segment Routing Networks", Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, Daniel Voyer, Rick Morton, 2020-02-09, Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric. "OAuth 2.0 Assisted Token", Jacob Ideskog, Travis Spencer, 2020-05-21, 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. "The Series Transfer Pattern (STP)", Carsten Bormann, Klaus Hartke, 2020-04-07, Many applications make use of Series of data items, i.e., an array of data items where new items can be added over time. Where such Series are to be made available using REST protocols such as CoAP or HTTP, the Series has to be mapped into a structure of one or more resources and a protocol for a client to obtain the Series and to learn about new items. Various protocols have been standardized that make Series-shaped data available, with rather different properties and objectives. The present document is an attempt to extract a common underlying pattern and to define media types and an access scheme that can be used right away for further protocols that provide Series-shaped data. "In-situ OAM raw data export with IPFIX", Mickey Spiegel, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, 2020-03-09, 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 Lozano, Eduardo Alvarez, 2020-03-26, This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents in order 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-05-20, 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. "IS-IS Multi Topology Deployment Considerations", Uma Chunduri, Jeff Tantsura, Shraddha Hegde, 2020-05-17, 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. "JSON Canonicalization Scheme (JCS)", Anders Rundgren, Bret Jordan, Samuel Erdtman, 2020-01-20, Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer end points, generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). The JCS specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the I-JSON subset, and by using deterministic property sorting. "SR Policy Implementation and Deployment Considerations", Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes, 2020-04-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-05-20, 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. "Hybrid Information-Centric Networking", Luca Muscariello, Giovanna Carofiglio, Jordan Auge, Michele Papalini, Mauro Sardara, 2020-05-20, This document describes the hybrid information-centric networking (hICN) architecture for IPv6. The specifications describe a way to implement information-networking functionalities into IPv6. The objective is to use IPv6 without creating overlays with a new packet format as an additional encapsulation. The intent of the present design is to introduce some IPv6 routers in the network with additional packet processing operations to implement ICN functions. Moreover, the current design is tightly integrated into IPv6 to allow easy interconnection to IPv6 networks with the additional design objective to exploit existing IPv6 protocols as much as possible as they are, or extend them where needed. "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen, 2020-05-25, 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. "Limited Domains and Internet Protocols", Brian Carpenter, Bing Liu, 2020-02-02, There is a noticeable trend towards network behaviours and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF, but is not the product of IETF conensus. "The IPv6 Tunnel Payload Forwarding (TPF) Option", Ron Bonica, Yuji Kamite, Luay Jalil, Yifeng Zhou, Gang Chen, 2020-03-06, This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. "A Massive Data Migration Framework", Can Yang, Yu Pan, Cong Chen, Ge Chen, Yukai Wei, 2019-11-26, This document describes a standardized framework for implementing the massive data migration between traditional databases and big-data platforms on the cloud via Internet, especially for an instance of Hadoop data architecture. The main goal of the framework is to provide more concise and friendly interfaces for users more easily and quickly migrate the massive data from a relational database to a distributed platform for a variety of requirements, in order to make full use of distributed storage resource and distributed computing capability to solve the bottleneck problems of both storage and computing performance in traditional enterprise-level applications. This document covers the fundamental architecture, data elements specification, operations, and interface related to massive data migration. "BGP FlowSpec Payload Matching", Anurag Khare, John Scudder, Luay Jalil, Michael Gallagher, Kirill Kasavchenko, 2019-12-07, 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 types, the varying motivations of their attackers, as well as the resulting business and reputation loss of their targets. BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") can be used to rapidly disseminate filters that thwart attacks, being particularly effective against the volumetric type. Operators can use existing FlowSpec components to match on pre-defined packet header fields. However recent enhancements to forwarding plane filter implementations allow matches at arbitary locations within the packet header and, to some extent, the payload. This capability can be used to detect highly amplified attacks whose attack signature remains relatively constant while values in the packet header vary, as well as the burgeoning variety of tunneled traffic. 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 bounded match conditions using bit offsets and a variety of match types. "PCEP extension to support Segment Routing Policy Candidate Paths", Mike Koldychev, Siva Sivabalan, Colby Barth, Cheng Li, Hooman Bidgoli, 2020-05-04, 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 via an 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. "Preferred Path Routing (PPR) in IS-IS", Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu, 2020-03-08, This document specifies Preferred Path Routing (PPR), a routing protocol extension to simplify the path description on the packet for Segment Routing (SR) deployments and beyond. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overhead; and also supports further extensions along the paths. "Anchorless mobility management through hICN (hICN-AMM): Deployment options", Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini, 2020-01-06, A novel mobility management approach is described in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, also referred to as Hybrid ICN (hICN) [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila]. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. In virtue of its anchorless property, we denote this approach as hICN- AMM (hICN Anchorless Mobility Management) hereinafter. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U. "Preferred Path Routing (PPR) in OSPF", Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras, 2020-03-08, This document specifies a Preferred Path Routing (PPR), a routing protocol mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports further extensions along the paths. Preferred path routing is achieved through the addition of path descriptions to the OSPF advertised prefixes, and mapping those to a PPR data-plane identifier. "PIM Backup Designated Router Procedure", mankamana mishra, Joseph Goh, Gyan Mishra, 2020-04-27, On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it. "PCE Controlled ID Space", Cheng Li, Mach Chen, Jie Dong, Zhenbin Li, Aijun Wang, Weiqiang Cheng, Chao Zhou, 2020-01-11, 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. Furthermore, PCEP can be used for computing paths in 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 delete PCE-initiated LSPs 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 where to make allocations on behalf of PCC. This document describes a mechanism for PCC to inform the PCE of the identifier space under its control via PCEP. The identifier could be MPLS label, SID or any other to-be-defined identifier to be allocated by a PCE. "Anchorless mobility through hICN", Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini, 2020-01-06, This document first discusses the use of locators and identifiers in mobility management architectures, and their implication on various anchorless properties. A new architecture is then proposed that is purely based on identifiers, and more specifically names as defined in Hybrid-ICN (hICN) [I-D.muscariello-intarea-hicn]. The document then focuses on two main cases: the end-point sends data (data producer) or the end-point receives data (data consumer). These two cases are taken into account entirely to provide anchorless mobility management in hICN. "IGP Extensions for Segment Routing based Enhanced VPN", Jie Dong, Zhibo Hu, Zhenbin Li, Stewart Bryant, 2020-03-09, Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require enhanced isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. To meet the requirement of enhanced VPN services, a number of Virtual Transport Networks (VTN) need to be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific VPN+ service, or a group of VPN+ services. This document specifies the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based VTNs. The VTNs could be used as the underlay of enhanced VPN service. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for QUIC", Vincent Roca, Francois Michel, Ian Swett, Marie-Jose Montpetit, 2020-03-09, This document specifies Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for the QUIC transport protocol, in order to recover from packet losses. "Identification of Overlay Operations, Administration, and Maintenance (OAM)", Greg Mirsky, 2020-02-26, This document analyzes how the presence of Operations, Administration, and Maintenance (OAM) control command and/or special data is identified in some overlay networks and an impact on the choice of identification may have on OAM functionality. "TLS 1.3 Authentication and Integrity only Cipher Suites", Nancy Cam-Winget, Jack Visoky, 2020-01-03, There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though mutual authentication during tunnel establishment and message integrity is still mandated. This document defines the use of HMAC only cipher suites for TLS 1.3. "pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake", Hernani Marques, Bernie Hoeneisen, 2020-01-08, In interpersonal messaging end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily authenticate their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark, 2019-12-16, This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. "BGP-LS Extensions for Advertising Path MTU", Yongqing Zhu, Zhibo Hu, Gang Yan, Junda Yao, 2020-01-06, 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 specify the extension 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. "Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT", Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki Ishida, 2020-01-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-05-07, 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-03-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-04-24, 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. "pretty Easy privacy (pEp): Mapping of Privacy Rating", Hernani Marques, Bernie Hoeneisen, 2020-01-08, In many Opportunistic Security scenarios end-to-end encryption is automatized for Internet users. In addition, it is often required to provide the users with easy means to carry out authentication. Depending on several factors, each communication channel to different peers may have a different Privacy Status, e.g., unencrypted, encrypted and encrypted as well as authenticated. Even each message from/to a single peer may have a different Privacy Status. To display the actual Privacy Status to the user, this document defines a Privacy Rating scheme and its mapping to a traffic-light semantics. A Privacy Status is defined on a per-message basis as well as on a per-identity basis. The traffic-light semantics (as color rating) allows for a clear and easily understandable presentation to the user in order to optimize the User Experience (UX). This rating system is most beneficial to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). "Multiple ALTO Resources Query Using Multipart Message", J. Zhang, Y. Yang, 2020-03-09, 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, 2020-01-09, 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-01-23, This document describes the use of the LISP Control Plane to support endpoint mobility and Location/ID separation in Segment Routing v6 (SRv6) deployments. "ALTO Extension: Unified Resource Representation", Qiao Xiang, Jensen Zhang, Franck Le, Y. Yang, 2020-03-09, The ALTO protocol [RFC7285] provides network information to applications so that applications can make network informed decisions to improve the performance. However, the base ALTO protocol only provides coarse-grained end-to-end metrics, which are insufficient to satisfy the demands of applications to solve more complex network optimization problems. The ALTO Path Vector extension [DRAFT-PV] has been introduced to allow ALTO clients to query information such as capacity regions for a given set of flows. However, the current design of this extension has a limited expressiveness. The goal of this document is to introduce a unified resource representation service as an extension of ALTO (ALTO-UR), which allows the ALTO clients to query and get the capacity regions of more complex resource information, such as Shared-Risk-Link-Group (SRLG), multi- path routing, multicast and on-demand routing, for a given set of flows. "Terminology for Cryptoassets", Hirotaka Nakajima, Masanori Kusunoki, Keiichi Hida, Yuji Suga, Tatsuya Hayashi, 2019-12-31, This document provides terminology used in cryptoassets. "A YANG Data Model for Network Bridge Management", Vladimir Vassilev, 2020-01-05, This document introduces new YANG model of a network bridge. "Flexible Session Protocol", Jun-an, Gao, 2020-04-18, 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 support 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-03-09, 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 should be mapped to transport 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 segments use to grant transport layer services. This is based on mapping between mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment Routing). Applicability of this framework 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 also discussed. "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-01-07, BGP Link-State (BGP-LS) enables distribution of topology information from the network to a Path Computation Engine (PCE) or any controller/application in general so it can learn the network topology. Service functions are deployed as, physical or virtualized elements along with network elements or on servers in data centers. The advertisement of such attached service capabilities along with the network nodes that they are attached to or associated with enables their discovery and the programming of service paths that use these service functions. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. SR Policies enable the setup of paths which are a mix of topological and service segments. This document specifies the extensions to BGP-LS for discovery and advertisement of service segments to enable the setup of service programming paths using Segment Routing. "BGP Automated Session Setup", Robert Raszuk, 2019-12-11, This document proposes a solution for BGP deployments in some specific environments to automatically establish BGP sessions without need for manual peer configuration. "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee Lindem, Peter Psenak, 2020-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 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. "The Decentralized Identifier (DID) in the DNS", Alexander Mayrhofer, Dimitrij Klesev, Markus Sabadello, 2020-02-24, This document specifies the use of the URI Resource Record Type to publish Decentralized Identifiers (DIDs) in the DNS. "Access Extensions for ANCP", Hongyu Li, Thomas Haag, Birgit Witschurke, 2020-04-03, 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-02-27, 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. "Anycast-SID FRR in SR", Ran Chen, Shaofu Peng, Jie Han, 2020-02-21, This document specifies the fast redundancy protection mechanism, aimed at providing protection of the links and domain boundary nodes for network that use segment routing. "Asymmetric Extended Route Optimization (AERO)", Fred Templin, 2020-05-20, This document specifies the operation of IP over tunnel virtual links using Asymmetric Extended Route Optimization (AERO). AERO interfaces 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. "Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2", Valery Smyslov, 2019-12-17, The Internet Key Exchange Protocol version 2 (IKEv2) defined in [RFC7296] uses UDP transport for its messages. [RFC8229] specifies a way to encapsulate IKEv2 and ESP (Encapsulating Security Payload) messages in TCP, thus making possible to use them in network environments that block UDP traffic. However, some nuances of using TCP in IKEv2 are not covered by that specification. This document provides clarifications and implementation guidelines for [RFC8229]. "Guide for building an EDDSA pki", Robert Moskowitz, Henk Birkholz, Michael Richardson, 2020-03-09, 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. "Loading MUD URLs from QR codes", Michael Richardson, Jacques Latour, Hassan Gharakheili, 2020-03-06, 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. The document describes extensions to the WiFi Alliance DPP QR code to support the use of MUD URLs. "Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) Test Vectors", Sam Whited, 2020-04-24, This document contains machine readable test vectors for several Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) profiles. "A YANG Model for Network and VPN Service Performance Monitoring", Qin WU, Mohamed Boucadair, Oscar de Dios, Bin Wen, Chang Liu, Honglei Xu, 2020-04-22, 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 model is designed as an augmentation to the network topology YANG data model defined in RFC8345. "The OPAQUE Asymmetric PAKE Protocol", Hugo Krawczyk, 2020-05-14, This draft 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. Prior aPAKE protocols did not use salt and if they did, the salt was transmitted in the clear from server to user allowing for the building of targeted pre-computed dictionaries. OPAQUE security has been proven by Jarecki et al. (Eurocrypt 2018) in a strong and universally composable formal model of aPAKE security. In addition, the protocol provides forward secrecy and the ability to hide the password from the server even during password registration. Strong security, versatility through modularity, good performance, and an array of additional features make OPAQUE a natural candidate for practical use and for adoption as a standard. To this end, this draft presents several instantiations of OPAQUE and ways of integrating OPAQUE with TLS. This draft presents a high-level description of OPAQUE highlighting its components and modular design. It also provides the basis for a specification for standardization but a detailed specification ready for implementation is beyond the current scope of this document (which may be expanded in future revisions or done separately). "A YANG Data model for ECA Policy Management", Henk Birkholz, Qin WU, Igor Bryskin, Xufeng Liu, Benoit Claise, 2020-05-12, This document defines a YANG data model for the Event Condition Action (ECA) policy management. The ECA policy YANG provides the ability for the network management function (within a network element) to control the configuration and monitor state change and take simple and instant action on the server when a trigger condition on the system state is met. "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse, Jordi Palet, Lee Howard, Richard Patterson, Ian Farrer, 2020-01-06, 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-05-06, 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-03-09, 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 OSCORE 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 OSCORE groups and to acquire information for joining them through the respective Group Manager. A given OSCORE 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 OSCORE groups based on the ACE framework for Authentication and Authorization in constrained environments. "The Mercure Protocol", Kevin Dunglas, 2020-04-03, Mercure is a protocol enabling the pushing of data updates to web browsers and other HTTP clients in a fast, reliable and battery- efficient way. It is especially useful for publishing real-time updates of resources served through web APIs to reactive web and mobile apps. "YANG Model for Transmission Control Protocol (TCP) Configuration", Michael Scharf, Vishal Murgai, Mahesh Jethanandani, 2020-02-24, This document specifies a YANG model for TCP on devices that are configured by network management protocols. The YANG model defines a container for all TCP connections and groupings of fundamental parameters that can be imported and used in many TCP implementations. The model includes definitions from YANG Groupings for TCP Client and TCP Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA (RFC 8342) compliant. "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-04-13, Egress Peer Engineering (EPE) is an application of Segment Routing to Solve the problem of egress peer selection. The Segment Routing based BGP-EPE solution allows a centralized controller, e.g. a Software Defined Network (SDN) controller to program any egress peer. The EPE solution requires a node to program the PeerNode 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. "Diffserv to QCI Mapping", Jerome Henry, Tim Szigeti, Luis Contreras, 2020-04-13, As communication devices become more hybrid, smart devices include more media-rich communication applications, and the boundaries between telecommunication and other applications becomes less clear. Simultaneously, as the end-devices become more mobile, application traffic transits more often between enterprise networks, the Internet, and cellular telecommunication networks, sometimes using simultaneously more than one path and network type. In this context, it is crucial that quality of service be aligned between these different environments. However, this is not always the case by default, and cellular communication networks use a different QoS nomenclature from the Internet and enterprise networks. This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS Identifiers (5QI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet. This mapping can be used by enterprises or implementers expecting traffic to flow through both types of network, and wishing to align the QoS treatment applied to one network under their control with the QoS treatment applied to the other network. "Basic YANG Model for Steering Client Services To Server Tunnels", Igor Bryskin, Vishnu Beeram, Tarek Saad, Xufeng Liu, Young Lee, Aihua Guo, 2020-01-12, This document describes a YANG data model for managing pools of transport tunnels and steering client services on them. "Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2020-03-14, This document defines a protocol to securely assign a pledge to an owner, using an intermediary node between pledge and owner. This intermediary node is known as a "constrained Join Proxy". This document extends the work of [ietf-anima-bootstrapping-keyinfra] by replacing the Circuit-proxy by a stateless constrained Join Proxy, that transports routing information. "Inband Flow Analyzer", Jai Kumar, Surendra Anubolu, John Lemon, Rajeev Manur, Hugh Holbrook, Anoop Ghanwani, Dezhong Cai, Heidi Ou, Li Yizhou, Xiaojun Wang, 2020-04-24, Inband Flow Analyzer (IFA) records flow specific information from an end station and/or switches across a network. This document discusses the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes a transport-agnostic header definition that may be used for tunneled and non-tunneled flows alike. "Postcard-based On-Path Flow Data Telemetry", Haoyu Song, Tianran Zhou, Zhenbin Li, Jongyoon Shin, Kyungtae Lee, 2020-04-13, The document describes a variation of the Postcard-Based Telemetry (PBT), the marking-based PBT. Unlike the instruction-based PBT, as embodied in [I-D.ietf-ippm-ioam-direct-export], the marking-based PBT does not require the encapsulation of a telemetry instruction header so it avoids some of the implementation challenges of the instruction-based PBT. This documents discuss the issues and solutions of the marking-based PBT. "BATS Coding Scheme for Multi-hop Data Transport", Shenghao Yang, Xuan Huang, Raymond Yeung, John Zao, 2020-05-25, 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. "Tethering A BIER Router To A BIER incapable Router", Zhaohui Zhang, Nils Warnke, IJsbrand Wijnands, Daniel Awduche, 2020-04-14, 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. "Path Segment for SRv6 (Segment Routing in IPv6)", Cheng Li, Weiqiang Cheng, Mach Chen, Dhruv Dhody, Rakesh Gandhi, 2020-03-03, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Further, Path Segment has been defined in order to identify an SR path in SR-MPLS networks, and used for various use-cases such as end- to-end SR Path Protection and Performance Measurement (PM) of an SR path. Similar to SR-MPLS, this document defines the Path Segment in SRv6 networks in order to identify an SRv6 path. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6", Mahendra Negi, Zhenbin Li, Xuesong Geng, Shuping Peng, 2020-03-09, 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 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", Mahendra Negi, Zhenbin Li, Xuesong Geng, Shuping Peng, 2020-03-09, 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/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for P2MP TE LSP. "Architecture for Use of BGP as Central Controller", Huaimo Chen, Shunwan Zhuang, Zhenbin Li, 2020-04-30, 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. "SRv6 Compatibility with Legacy Devices", Hui Tian, Feng Zhao, Chongfeng Xie, Tong Li, Jichun Ma, Shuping Peng, Zhenbin Li, Jim Guichard, 2020-01-08, When deploying SRv6 on legacy devices, there are some compatibility challenges that must be addressed such as the support for SRH processing. This document identifies some of the major challenges, and provides solutions that can mitigate those challenges and smooth the migration towards SRv6 deployment. "SR-TE Path Midpoint Protection", Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu, 2020-05-18, Segment Routing Traffic Engineering (SR-TE) supports the creation of explicit paths using segment lists containing adjacency-SIDs, node- SIDs, anycast-SIDs, and binding-SIDs. When the segment list defining an SR-TE path contains a node-SID, and the node fails, the network may no longer be able to properly forward traffic on that SR-TE path. [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and [I-D.hegde-spring-node-protection-for-sr-te-paths] describe a mechanism that allows local repair actions on the direct neighbors of the failed node to temporarily route traffic to the node immediately following the failed node on the SR-TE path segment list. However, once the IGP shortest paths have converged, the local repair mechanism is no longer sufficient to continue forwarding traffic using the original segment list of the SR-TE path, since the non- neighbors of the failed node will no longer have a route to reach the failed node. This document describes a mechanism that allows traffic to continue to be forwarded on an SR-TE path for an extended period of time after the failure of a node used in the path's segment list. "EtherType Protocol Identification of In-situ OAM Data", Brian Weis, Frank Brockners, Craig Hill, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel, 2020-05-13, 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 defines an EtherType that identifies IOAM data fields as being the next protocol in a packet, and a header that encapsulates the IOAM data fields. "Edge Data Discovery for COIN", Mike McBride, Dirk Kutscher, Eve Schooler, Carlos Bernardos, 2020-01-29, This document describes the problem of distributed data discovery in edge computing, and in particular for computing-in-the-network (COIN), 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. "Multicast/BIER As A Service", Zhaohui Zhang, Eric Rosen, Daniel Awduche, Liang Geng, 2020-05-24, This document describes a framework for providing multicast as a service via Bit Index Explicit Replication (BIER) [RFC7279], and specifies a few enhancements to [draft-ietf-bier-idr-extensions] [RFC8279] [draft-ietf-bier-ospf-bier-extensions] to enable multicast/ BIER as a service. "AC-Aware Bundling Service Interface in EVPN", Ali Sajassi, mankamana mishra, Samir Thoria, Patrice Brissette, Jorge Rabadan, John Drake, 2020-02-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, 2020-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-04-14, 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 . "CBOR Profile of X.509 Certificates", Shahid Raza, Joel Hoglund, Goeran Selander, John Mattsson, Martin Furuhed, 2020-03-09, This document specifies a CBOR encoding and profiling of X.509 public key certificate suitable for Internet of Things (IoT) deployments. The full X.509 public key certificate format and commonly used ASN.1 DER encoding is overly verbose for constrained IoT environments. Profiling together with CBOR encoding reduces the certificate size significantly with associated known performance benefits. The CBOR certificates are compatible with the existing X.509 standard, enabling the use of profiled and compressed X.509 certificates without modifications in the existing X.509 standard. "YANG Data Models for the IP Flow Information Export (IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export", Joey Boyd, Marta Seda, 2020-03-09, This document defines a flexible, modular YANG model for packet sampling (PSAMP) and bulk data collection and export via the IPFIX protocol. This new model replaces the model defined in RFC 6728, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". All functionality modeled in RFC 6728 has been carried over to this new model. The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 6728 (if approved). "Preferred Path Route Graph Structure", Uma Chunduri, Toerless Eckert, 2020-03-08, 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, Gaurav Dawra, Zhenbin Li, 2020-02-13, This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. "Resilient MPLS Rings using SPRING", Kireeti Kompella, Tarek Saad, Abhishek Deshmukh, 2020-03-09, This document describes the use of SPRING to setup LSP(s) for resilient MPLS ring networks. It specifies how clockwise and anti- clockwise ring SIDs are allocated and signaled using IGP protocol extensions, and how such ring SIDs achieve ring protection. "Private Discovery", Bob Bradley, 2020-02-11, This document specifies a mechanism for advertising and discovering in a private manner. "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, Shiying Pan, Haibo Sun, Kemin Qu, Guoqiang Han, 2020-05-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. "Realm Crossover for SASL and GSS-API via Diameter", Rick van Rein, 2020-01-21, SASL and GSS-API are used for authentication in many application protocols. This specification extends them to allow credentials of a home realm to be used against external services. To this end, it introduces end-to-end encryption for SASL that is safe to relay to the client's home realm. "Multiple Layer Resource Optimization for Optical as a Service", Hui Yang, Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang, 2020-05-02, 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. "Chacha derived AEAD algorithms in JSON Object Signing and Encryption (JOSE)", Guillaume Amringer, 2020-01-09, This document defines how to use the AEAD algorithms "AEAD_XCHACHA20_POLY1305" and "AEAD_CHACHA20_POLY1305" from [RFC8439] and [I-D.irtf-cfrg-xchacha] in JSON Object Signing and Encryption (JOSE). "Multiple Loss Ratio Search for Packet Throughput (MLRsearch)", Maciek Konstantynowicz, Vratko Polak, 2020-03-06, This document proposes changes to [RFC2544], specifically to packet throughput search methodology, by defining a new search algorithm referred to as Multiple Loss Ratio search (MLRsearch for short). Instead of relying on binary search with pre-set starting offered load, it proposes a novel approach discovering the starting point in the initial phase, and then searching for packet throughput based on defined packet loss ratio (PLR) input criteria and defined final trial duration time. One of the key design principles behind MLRsearch is minimizing the total test duration and searching for multiple packet throughput rates (each with a corresponding PLR) concurrently, instead of doing it sequentially. The main motivation behind MLRsearch is the new set of challenges and requirements posed by NFV (Network Function Virtualization), specifically software based implementations of NFV data planes. Using [RFC2544] in the experience of the authors yields often not repetitive and not replicable end results due to a large number of factors that are out of scope for this draft. MLRsearch aims to address this challenge in a simple way of getting the same result sooner, so more repetitions can be done to describe the replicability. "Probabilistic Loss Ratio Search for Packet Throughput (PLRsearch)", Maciek Konstantynowicz, Vratko Polak, 2020-03-06, This document addresses challenges while applying methodologies described in [RFC2544] to benchmarking software based NFV (Network Function Virtualization) data planes over an extended period of time, sometimes referred to as "soak testing". Packet throughput search approach proposed by this document assumes that system under test is probabilistic in nature, and not deterministic. "Security Classes for IoT devices", Pascal Urien, 2020-05-24, This draft attempts to define security classes for constraint IoT devices. A device security is characterized by five Boolean security attributes: one time programmable memory (OTP), firmware loader (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT- KEY) and diversified key (DIV-KEY). This leads to the definition of 6 classes of devices, embedding or not OTP resource, whose security increases with the class number (0 to 5). The suffix + indicates OTP availability. "Considerations for Large Authoritative DNS Servers Operators", Giovane Moura, Wes Hardaker, John Heidemann, Marco Davids, 2020-04-08, This document summarizes recent research work exploring Domain Name System (DNS) configurations and offers specific, tangible considerations to operators for configuring authoritative servers. It is possible that the considerations presented in this document could be applicable in a wider context, such as for any stateless/ short-duration, anycasted service. This document is not an IETF consensus document: it is published for informational purposes. "MessageVortex Protocol", Martin Gwerder, 2020-03-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 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. "Retransmit bit for SCTP DATA, I-DATA and SACK", Maksim Proshin, 2019-12-02, This document defines a method which helps an SCTP sender to understand when a received SACK acknowledges the original transmission of a TSN or its retransmission. It is done by specifying a new bit, called Retransmit bit (R-bit), in the header of DATA, I-DATA and SACK chunks. The bit is used when a TSN is retransmitted and returned back in the acknowledgement. This document updates [RFC4960] if approved. "Multicast DF Election for EVPN based on bandwidth or quantity", Yisong Liu, Mike McBride, 2019-11-26, Ethernet Virtual Private Network (EVPN, RFC7432) is becoming prevalent in Data Centers, Data Center Interconnect (DCI) and Service Provider VPN applications. When multi-homing from a CE to multiple PEs, including links in an EVPN instance on a given Ethernet Segment, in an all-active redundancy mode, [RFC7432] describes a basic mechanism to elect a Designated Forwarder (DF), and [RFC8584] improves basic DF election by a HRW algorithm. [I- D.ietf-bess-evpn-per-mcast-flow-df-election] enhances the HRW algorithm for the multicast flows to perform DF election at the granularity of (ESI, VLAN, Mcast flow). This document specifies a new algorithm, based on multicast bandwidth utilization and multicast state quantity, in order for the multicast flows to elect a DF. "Flooding Topology Computation Algorithm", Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2020-03-09, 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. "The Universal IPv6 Configuration Option (experiment)", Ole Troan, 2020-04-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. "The practice of NFV decoupling test", louie long, Yang Song, Zhijun Tang, 2019-12-16, This document mainly introduces the practice of NFV decoupling test. Based on the product development situation of the current vendors, the decoupling test is carried out between NFVI&VIM, VNFM&VNF and NFVO. Through a series of tests to explore some of the problems encountered in the current stage of NFV decoupling testing, provide ideas for the subsequent development of NFV products. "Generic Multi-Access (GMA) Encapsulation Protocol", Jing Zhu, Satish Kanugovi, 2020-05-14, Today, a device can be simultaneously connected to multiple networks, e.g. Wi-Fi, LTE, 5G, and DSL. It is desirable to combine them seamlessly to improve quality of experience. Such optimization requires additional control information, e.g. Sequence Number, in each (IP) data packet. This document presents a new light-weight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations. "CoRE Resource Directory Extensions", Christian Amsuess, 2020-03-03, 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 VI: The Trust Mesh", Phillip Hallam-Baker, 2020-03-09, 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-03-09, 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: o To detect if a host is up or down. o To measure the RTT and its variation over time. o 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: o OAM coming from internet. In that case, the NGW should act as a "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson, 2020-05-18, 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. "Probing IP Interfaces By Vendor Specific Identifiers", Manoj Nayak, Ron Bonica, Rafik Puttur, 2020-02-13, This document enhances the PROBE diagnostic tool so that it can identify the probed interface by Vendor Specific Identifiers. In order to achieve that goal, this document also extends the Interface Identification Object. The Interface Identification Object is an ICMP Extension Object class. "Benchmarking Methodology for EVPN Multicasting", sudhin jacob, Vikram Nagarajan, 2020-05-04, 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. "Resource Discovery in Constrained RESTful Environments (CoRE) using the Constrained RESTful Application Language (CoRAL)", Klaus Hartke, 2020-05-09, This document explores how the Constrained RESTful Application Language (CoRAL) might be used for two use cases in Constrained RESTful Environments (CoRE): CoRE Resource Discovery, which allows a client to discover the resources of a server given a host name or IP address, and CoRE Resource Directory, which provides a directory of resources on many servers. "Performance Measurement Using TWAMP Light for Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens, 2020-03-23, 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 procedure for sending and processing probe query and response messages for Performance Measurement (PM) in Segment Routing networks. The procedure uses the messages defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP) Light) for Delay Measurement, and uses the messages defined in this document for Loss Measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes and is used for both Links and end-to-end SR Policies. "TLS-based EAP types and TLS 1.3", Alan DeKok, 2020-04-19, 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. "A standard process to quarantine and restore IoT Devices", Michael Richardson, Jacques Latour, 2020-02-20, 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 the 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. "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip Hallam-Baker, 2020-03-09, 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, 2020-03-09, 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. "Extended Link Relationships", Jose Montoya, 2020-05-05, This document defines XREL, a data format for describing extended hypermedia relationships identified by Uniform Resource Locators. "Profiled Hypertext Application Language", Jose Montoya, 2020-05-05, This document defines PHTAL, a generic representation format for hypertext applications guided by REST constraints. PHTAL could be compared to HTML without any graphical objectives. "The Deprecation HTTP Header Field", Sanjay Dalal, Erik Wilde, 2019-12-19, 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. "The IPv6 Compact Routing Header (CRH)", Ron Bonica, Yuji Kamite, Tomonobu Niwa, Andrew Alston, Luay Jalil, 2020-05-14, This document defines two new Routing header types. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. "The Per-Segment Service Instruction (PSSI) Option", Ron Bonica, Joel Halpern, Yuji Kamite, Tomonobu Niwa, Luay Jalil, Gang Chen, Yongqing Zhu, Yifeng Zhou, 2020-03-06, SRm6 encodes Per-Segment Service Instructions (PSSI) in a new IPv6 option, called the PSSI Option. This document describes the PSSI Option. "Scenarios and Requirements for Layer 2 Autonomic Control Planes", Brian Carpenter, Bing Liu, 2020-04-08, This document discusses scenarios and requirements for Autonomic Control Planes (ACPs) constructed and secured at Layer 2. These would be alternatives to an ACP constructed and secured at the network layer. A secure ACP is required as the substrate for an autonomic network and for the Generic Autonomic Signaling Protocol (GRASP). "Multi-Path Concurrent Measurement for IPPM", Joanna Dang, Jianglong, Shinyoung Lee, 2020-05-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). "Transport parameters for 0-RTT connections", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom Jones, 2020-05-18, 0-RTT mechanisms reduce the time it takes for the first bytes of application data to be processed in a transport connection and can greatly reduce connection latency during setup. The 0-RTT transport features described by quic-transport help clients establish secure connections with a minimal number of round-trips. This document describes a generic method to exchange path parameters relating to transport. The additional transport parameters can help a connection that continues after an interruption or restarts by sharing connection properties. They can be used to increase the performance for a path with large RTT. "Bidirectional Forwarding Detection (BFD) for EVPN Ethernet Segment Failover Use Case", Zheng Zhang, Yubao Wang, Greg Mirsky, 2020-05-18, This document introduces a method for fast switchover of Designated Forwarder for Ethernet Segment failover by using Bidirectional Forwarding Detection protocol. "BGP Provisioned IPsec Tunnel Configuration", Jun Hu, 2020-03-09, This document defines a method of using BGP to provide IPsec tunnel configuration along with NLRI, it uses and extends tunnel encapsulation attribute as specified in [I-D.ietf-idr-tunnel-encaps] for IPsec tunnel. "Extended Bidirectional Forwarding Detection", Greg Mirsky, Xiao Min, 2020-04-14, This document describes a mechanism to extend the capabilities of Bidirectional Forwarding Detection (BFD). These extensions enable BFD to measure performance metrics like packet loss and packet delay. Also, a method to perform lightweight on-demand authentication is defined in this specification. "Proxy IP->MAC Advertisement in EVPNs", Ryan Bickhart, Wen Lin, John Drake, Jorge Rabadan, Alton Lo, 2020-01-24, This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN type 2 IP->MAC advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. "LOOPS (Localized Optimizations on Path Segments) Problem Statement and Opportunities for Network-Assisted Performance Enhancement", Li Yizhou, Xingwang Zhou, Mohamed Boucadair, Jianglong Wang, 2020-01-06, In various network deployments, end to end forwarding paths are partitioned into multiple segments. For example, in some cloud-based WAN communications, stitching multiple overlay tunnels are used for traffic policy enforcement matters such as to optimize traffic distribution or to select paths exposing a lower latency. Likewise, in satellite communications, the communication path is decomposed into two terrestrial segments and a satellite segment. Such long- haul paths are naturally composed of multiple network segments with various encapsulation schemes. Packet loss may show different characteristics on different segments. Traditional transport protocols (e.g., TCP) respond to packet loss slowly especially in long-haul networks: they either wait for some signal from the receiver to indicate a loss and then retransmit from the sender or rely on sender's timeout which is often quite long. Non-congestive loss may make the TCP sender over-reduce the sending rate unnecessarily. With the increase of end-to-end transport encryption (e.g., QUIC), traditional PEP (performance enhancing proxy) techniques such as TCP splitting are no longer applicable. LOOPS (Local Optimizations on Path Segments) is a network-assisted performance enhancement over path segment and it aims to provide local in-network recovery to achieve better data delivery by making packet loss recovery faster and by avoiding the senders over-reducing their sending rate. In an overlay network scenario, LOOPS can be performed over a variety of the existing, or purposely created, tunnel-based path segments. "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Sun Kj, Hyunsik Yang, ykpark@dcn.ssu.ac.kr, Young-Han Kim, Wangbong Lee, 2020-03-09, 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. "Encapsulation for BIER in Non-MPLS IPv6 Networks", Jingrong Xie, Liang Geng, Mike McBride, Rajiv Asati, Senthil Dhanaraj, 2020-03-09, This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- MPLS IPv6 Networks using the IPv6 Destination Option extension header. This document updates [RFC8296]. "Composite Keys and Signatures For Use In Internet PKI", Mike Ounsworth, Massimiliano Pala, 2020-01-16, 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-03-04, This document introduces new YANG model for use in network interconnect testing containing modules for traffic generator and traffic analyzer. "Considerations for ID/Location Separation Protocols in IPv6-based Vehicular Networks", Sun Kj, Young-Han Kim, 2020-03-09, 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, Joel Halpern, Ting Ao, Wei Wei, Xufeng Liu, 2020-02-07, 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-03-07, 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. "DetNet SRv6 Data Plane Encapsulation", Xuesong Geng, Mach Chen, Yongqing Zhu, 2020-03-12, This document specifies Deterministic Networking data plane operation for SRv6 encapsulated user data. "Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence", Junkyun Choi, Jaeseob Han, Gyeong Lee, Na Kim, 2020-05-19, 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, 2020-01-13, 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. "Support of asynchronous Enrollment in BRSKI", Steffen Fries, Hendrik Brockhaus, Eliot Lear, 2020-03-06, This document discusses enhancements of bootstrapping of a remote secure key infrastructure (BRSKI) to also operate in domains featuring no or only timely limited connectivity to backend services offering enrollment functionality, specifically a Public Key Infrastructure (PKI). The enhancements proposed to enable this are also applied to further set of use cases in which a pledge may not have a direct connection to the registrar and is served by for instance by a commissioning tool as an agent providing registrar connectivity. In the context of deploying new devices the design of BRSKI allows for online (synchronous object exchange) and offline interactions (asynchronous object exchange) with a manufacturer's authorization service. For this it utilizes an authenticated self- contained voucher to transport the domain credentials as a signed object to establish an initial trust between a pledge and the target deployment domain. The currently supported enrollment protocol for request and distribution of deployment domain specific device certificates provides only limited support for asynchronous PKI interactions. This memo motivates the enhancement of supporting authenticated self-contained objects for certificate management by using an abstract notation. The enhancement allows on one hand off- site operation of PKI services outside the deployment domain of the pledge. This addresses specifically scenarios, in which the final authorization of a certification request of a pledge cannot be made in the deployment domain and is therefore delegated to a operator backend. On the other hand, this enhancement also facilitates the exchange of certificate management information via a pledge agent. The goal is to enable the usage of existing and potentially new PKI protocols supporting authenticated self-containment for certificate management exchanges. "Deployment Considerations for In-situ OAM with IPv6 Options", Shwetha Bhandari, Frank Brockners, Tal Mizrahi, Aviv Kfir, Barak Gafni, Mickey Spiegel, Suresh Krishnan, Mark Smith, 2020-03-29, 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 can be enabled in an IPv6 network. "BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf, Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2020-01-05, 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, 2019-12-13, 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, 2020-01-11, 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. "YANG Data Models for Multiprotocol Label Switching - Transport Profile", Italo Busi, Haomian Zheng, 2020-04-20, Multi-protocol Label Switching - Transport Profile (MPLS-TP) is a profile of the MPLS protocol that is used in packet switched transport networks and operated in a similar manner to other existing transport technologies (e.g., OTN), as described in RFC5921. This document specifies YANG models for MPLS-TP, which have not been covered by existing models so far. The gap analysis with current relevant traffic-engineering (TE) and MPLS models is also included. "Arm's Platform Security Architecture (PSA) Attestation Token", Hannes Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati, 2020-03-06, The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. 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. "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2020-01-02, 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. "BRSKI enrollment of with disconnected Registrars -- smarkaklink", Michael Richardson, Jacques Latour, 2020-03-09, 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, 2020-01-01, 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. "Deprecation of IKEv1 and obsoleted algorithms", Paul Wouters, 2019-12-30, Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. IANA is instructed to close all IKEv1 registries. "Use cases for Remote Attestation common encodings", Michael Richardson, Carl Wallace, Wei Pan, 2020-03-09, 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-05-18, 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. "QoS Treatments in ICN using Disaggregated Name Components", Anil Jangam, Prakash suthar, Milan Stolic, 2020-03-09, Mechanisms for specifying and implementing end-to-end Quality of service (QoS) treatments in Information-Centric Networks (ICN) has not been explored so far. There has been some work towards implementing QoS in ICN; however, the discussions are mainly centered around strategies used in efficient forwarding of Interest packets. Moreover, as ICN has been tested mainly as an IP overlay, its QoS is still governed by the IP QoS framework and there is a need for implementing QoS in ICN natively. This document describes mechanisms to classify and provide associated "name-based" extensions to identify QoS within the framework of ICN's core design principles. The name-based design provides a mechanism to carry QoS information and implement the treatments as ICN packets travel across different routers in the ICN network. Detailed discussion is provided for QoS specific procedures in each of the ICN network elements i.e. consumer, producer, and forwarder. "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-02-06, 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-03-09, Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. "Multi-domain E2E Network Services", Danny Perez, Christian Rothenberg, 2020-03-09, Evolving networking scenarios (e.g., 5G) are considering the provision of value-added and on-demand end-to-end (E2E) network services in multi-domain (multi-operator/multi-technology) environments. This document presents different initiatives, mainly within standardization efforts and research projects, working on E2E network services across multiple domains. Problem statement and a layered network model are also described. In addition, this document raises an initial proposal towards a new ALTO service in support of E2E network service requirements. Finally, another important objective of this document is to begin a discussion about motivating use cases in scope of the ALTO WG after the re-chartering process. "Reference Interaction Models for Remote Attestation Procedures", Henk Birkholz, Michael Eckel, 2020-01-07, This document defines interaction models for basic remote attestation procedures. Different methods of conveying attestation evidence securely are defined and illustrated. Analogously, the required information elements used by conveyance protocols are defined and illustrated. "Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann, 2020-03-09, This documents defines the method and bindings used to conduct Time- based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) Principals over the Internet. 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. Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester. As a prerequisite for TUDA, every RATS Principal requires access to a trusted and synchronized time-source. Per default, in TUDA this is a Time Stamp Authority (TSA) issuing signed Time Stamp Tokens (TST). "SRv6 Implementation and Deployment Status", Satoru Matsushima, Clarence Filsfils, Zafar Ali, Zhenbin Li, Kalyani Rajaraman, 2020-04-20, 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. "Capabilities and Limitations of an Endpoint-only Security Solution", Arnaud Taddei, Candid Wueest, Kevin Roundy, Dominique Lazanski, 2020-01-09, In the context of existing, proposed and newly published protocols, this draft RFC is to establish the capabilities and limitations of endpoint-only security solutions and explore benefits and alternatives to mitigate those limits with the support of real case studies. "Simplifying Firewall Rules with Network Programming and SRH Metadata", Jim Guichard, Clarence Filsfils, daniel.bernier@bell.ca, Zhenbin Li, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam, 2020-04-08, A clear application of the SRv6 Network Programming model consists in steering, in a stateless manner, packets through a Service Function Chain (SFC). Each Service Function (SF) is identified by a segment. Each SF can enrich its operation thanks to metadata present in the SRH. This document describes a practical use-case where the SF is a firewall and the metadata helps to drastically decrease the number of rules that need to be maintained by the operation team. "Concise Binary Object Representation (CBOR) Tag for Coordinate Reference System (CRS) Specification", Trevor Clarke, 2020-03-17, 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. In CBOR, one point of extensibility is the definition of CBOR tags. An existing CBOR tag, 103, allows for the representation of geographic coordinates. Proper exploitation of geographic coordinates requires an associated reference frame. The present document defines a CBOR tag for referencing the coordinate reference system (CRS) for a geographic coordinate. It is intended as the reference document for the IANA registration of the CBOR tag defined. "Network File System Version 4 Requirements for Computational Storage", Chuck Lever, 2020-02-03, This document proposes an architecture to support Computational Storage using Network File System version 4 (NFS) files. "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-02-19, 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-03-06, 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. In particular, this document specifies the use of the Bit Flipping Key Exchange (BIKE) and Supersingular Isogeny Key Exchange (SIKE) schemes in combination with ECDHE as a hybrid key agreement in a TLS 1.2 handshake. "Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon Jeong, Yiwen Shen, Zhong Xiang, 2020-05-07, This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory. "Registry Lock Extension for the Extensible Provisioning Protocol (EPP)", Ulrich Wisser, 2020-04-07, This extensions defines an additional protective layer for changes to domain [RFC5731], host [RFC5732] and contact [RFC5733] objects managed through EPP. EPP allows changes to objects only by the sponsoring client. EPP objects are usually managed by the sponsoring client on behalf of the sponsoring clients customers. All of these interactions are ususally fully automated. In case of a system breach, there is no protection in EPP to changes to any object by the intruder. This extension defines a protective layer that aims to break automated changes and work flows by requiring manual intervention by the sponsoring client or it's customers. "Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, Tony Whyman, 2020-02-17, Mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, mobile enterprise 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 IPv6 packets over Overlay Multilink Network (OMNI) Interfaces. "IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White, Shraddha Hegde, Shawn Zandi, 2020-04-03, 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. "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip Hallam-Baker, 2020-01-16, 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-03-09, 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, 2020-03-09, 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, 2020-01-16, 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. "Packet Loss Signaling for Encrypted Protocols", Alexandre Ferrieux, Isabelle Hamchaoui, Igor Lubashev, Dmitri Tikhonov, 2020-01-16, This document defines an extension to the QUIC transport protocol to allow endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [1] or on the GitHub repository which contains the draft: https://github.com/igorlord/draft- ferrieuxhamchaoui-lossbits [2]. "ARP/ND Synching And IP Aliasing without IRB", Yubao(Bob) Wang, Zheng Zhang, 2020-05-10, This document proposes an extension to [RFC7432] and [I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP aliasing for Layer 3 routes that is needed for EVPN signalled L3VPN to build a complete IP ECMP. The phrase "EVPN signalled L3VPN" means that there may be no MAC-VRF or IRB interface in the use case. When there are no MAC-VRF or IRB interface, EVPN signalled L3VPN is also called as "pure L3VPN instance" which is a different usecase from [I-D.sajassi-bess-evpn-ip-aliasing]. "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2020-03-09, 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. "IPv6 Neighbor Discovery on Wireless Networks", Pascal Thubert, 2020-03-31, This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media. "L3DL Upper Layer Protocol Configuration", Randy Bush, Keyur Patel, 2020-05-06, This document users the Layer 3 Liveness and Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper layer protocols such as the BGP family. "YANG Model for IGP Flexible Algorithm", Mobashshera Rasool, Sreekanth S, Mahendra Negi, 2020-01-09, This document describes a YANG data model for IGP Flexible Algorithm. The model serves as a base framework for configuring and managing Flexible Algorithms which is used by IGPs to compute constraint based paths over the network. "Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou, Lifen Zhou, 2020-04-27, 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 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", Chathura Sarathchandra, Dirk Trossen, Michael Boniface, 2020-02-28, The application-centric deployment of 'Internet' services has increased over the past ten years with many million 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 of 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-05-21, 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 order to support 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. "Service Oriented Internet Protocol", Brian Carpenter, Sheng Jiang, Guangpeng Li, 2020-05-14, This document proposes a new, backwards-compatible, approach to packet forwarding, where the service required rather than the IP address required acts as the vector for routing packets at the edge of the network. Deeper in the network, the mechanism can interface to conventional and future methods of service or application aware networking. "Incrementally Better Cookies", Mike West, 2020-03-15, This document proposes a few changes to cookies inspired by the properties of the HTTP State Tokens mechanism proposed in [I-D.west-http-state-tokens]. First, cookies should be treated as "SameSite=Lax" by default. Second, cookies that explicitly assert "SameSite=None" in order to enable cross-site delivery should also be marked as "Secure". Third, same-site should take the scheme of the sites into account. Fourth, cookies should respect schemes. Fifth, cookies associated with non-secure schemes should be removed at the end of a user's session. Sixth, the definition of a session should be tightened. "Public Key Authenticated Encryption for JOSE: ECDH-1PU", Neil Madden, 2020-02-11, This document describes the ECDH-1PU public key authenticated encryption algorithm for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but adds an additional ECDH key agreement between static keys of the sender and recipient. This additional step allows the recipient to be assured of sender authenticity without requiring a nested signed-then-encrypted message structure. "Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)", Derek Atkins, 2019-12-20, 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 constrained16807 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. "IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)", Parag Kaneriya, Rejesh Shetty, Shraddha Hegde, Ron Bonica, 2020-03-23, 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. "Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report", Kathleen Moriarty, 2020-05-19, The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned regional, national, international, and enterprise CSIRTs, operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus for CARIS 2 scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption. "Transactional Authorization", Justin Richer, 2020-04-22, This document defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. "Reliable and Available Wireless Technologies", Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas, 2020-05-18, This document presents a series of recent technologies that are capable of time synchronization and scheduling of transmission, making them suitable to carry time-sensitive flows with high reliability and availbility. "LOOPS Generic Information Set", Michael Welzl, Carsten Bormann, 2020-03-09, LOOPS (Local Optimizations on Path Segments) aims to provide local (not end-to-end but in-network) recovery of lost packets to achieve better data delivery in the presence of losses. [I-D.li-tsvwg-loops-problem-opportunities] provides an overview over the problems and optimization opportunities that LOOPS could address. The present document is a strawman for the set of information that would be interchanged in a LOOPS protocol, without already defining a specific data packet format. The generic information set needs to be mapped to a specific encapsulation protocol to actually run the LOOPS optimizations. The current version of this document contains sketches of bindings to GUE [I-D.ietf-intarea-gue] and Geneve [I-D.ietf-nvo3-geneve]. "Asymmetric IPv6 for IoT Networks", Sheng Jiang, Guangpeng Li, Brian Carpenter, 2020-05-14, 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. "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan, 2019-12-02, 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. "New IPv6 Multicast Addresses for Switch ML", Hemant Singh, 2019-12-09, Recently, in-network aggregation to scale distributed machine learning (ML) has been presented. A network switch implementation uses IPv4 broadcast messages from switch to the hosts to send updates to all workers. IPv6 does not support broadcast addresses. This document proposes, IPv6 implementations use the IPv6 link-local all- nodes multicast address, until a new IPv6 link-local multicast address is assigned by IANA for switch to hosts multicast communications. "Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao, 2020-05-09, 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, 2019-11-29, 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, Shuying Zhuang, Miao Congcong, Changqing An, 2019-12-13, 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 a cyberspace map on this basis. "Exploiting Packet Replication and Elimination in Complex Tracks in LLNs", Georgios Papadopoulos, Remous-Aris Koutsiamanis, Nicolas Montavont, Pascal Thubert, 2020-01-02, The Packet Replication and Elimination (PRE) mechanism duplicates data packets into several paths in the network to increase reliability and provide low jitter. PRE may be used to complement layer-2 Automatic Repeat reQuest (ARQ) and receiver-end Ordering to form the PAREO functions. Over a wireless medium, this technique can take advantage of communication Overhearing, when parallel transmissions over two adjacent paths are scheduled. This document presents the concept and details the required changes to the current specifications that will be necessary to enable the PAREO functions. "GOST R 34.12-2015: Block Cipher "Magma"", Vasily Dolmatov, Dmitry Eremin-Solenikov, 2020-03-22, In addition to a new cipher with block length of n=128 bits (referred to as "Kyznyechik" and described in RFC 7801) Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with block length of n=64 bits and key length k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of GOST 64-bit cipher with the revised version of the cipher for encryption and decryption. "A Framework for Constructing Service Function Chaining Systems Based on Segment Routing", Cheng Li, Ahmed El Sawaf, Ruizhao Hu, Zhenbin Li, 2020-05-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. 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. "Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute", Yisong Liu, Mike McBride, 2019-11-23, Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], but the selection of the secondary multicast next hop only according to the loop-free alternate fast reroute, which has restrictions in multicast deployments. This document describes a mechanism for Multicast-only Fast Reroute by using Topology Independent Loop-free Alternate fast reroute, which is independent of network topology and can achieve covering more network environments. "IS-IS Flooding Parameters advertisement", Bruno Decraene, Chris Bowers, Jayesh J, Tony Li, Gunter Van de Velde, 2020-03-09, This document proposes a mechanism that can be used to increase the speed at which link state information is exchanged between two routers when multiple LSPs need to be flooded, such as in case of a node failure. It also reduces the likelihood of overloading the router receiving the LSPs. This document defines a new TLV to be advertised in SNP and or Hello messages. This TLV may carry a set of parameters indicating the performance capacity to receive LSPs: the number of LSPs which can the received back to back, the minimum delay between further two consecutive LSPs and the minimum delay before retransmission of an LSP. "BIER IPv6 Encapsulation (BIERv6) Support via IS-IS", Jingrong Xie, Aijun Wang, Gang Yan, Senthil Dhanaraj, 2020-01-13, This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) with IPv6 encapsulation (BIERv6). "Requirement and Solution for Multicast Traffic On-path Telemetry", Haoyu Song, Mike McBride, Greg Mirsky, 2020-04-07, This document discusses the requirement of on-path telemetry for multicast traffic. The existing solutions are examined and their issues are addressed with new modifications that adapt to the multicast scenario. "Deterministic Networking (DetNet) Controller Plane Framework", Andrew Malis, Xuesong Geng, Mach Chen, Fengwei Qin, 2020-01-20, 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-02-27, 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. "QUIC for SATCOM", Nicolas Kuhn, Gorry Fairhurst, John Border, Stephan Emile, 2020-03-06, QUIC has been designed for use across Internet paths. Initial designs of QUIC have focussed on common deployment scenarios for web traffic and have not focussed on the performance when using a path with a large Bandwidth-Delay Product (BDP). A path can combine satellites network segment together with a wide variety of other network technologies (Ethernet, cable modems, WiFi, cellular, radio links, etc): this complicates the characteristics of the end-to-end path. One example of such a scenario occurs when a satellite communication (SATCOM) system is used to provide all or a part of the end-to-end path. If this is not addressed, the end-to-end quality of experience can be degraded. 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. "TPM-based Network Device Remote Integrity Verification", Guy Fedorkow, Eric Voit, Jessica Fitzgerald-McKay, 2020-04-16, This document describes a workflow for remote attestation of integrity of network devices. "Carrying SID Algorithm information in PCE-based Networks.", Alexej Tokar, Siva Sivabalan, Mahendra Negi, 2019-12-31, 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. "Inter-Domain Multicast Deployment using BIERv6", Liang Geng, Jingrong Xie, Mike McBride, Gang Yan, 2020-01-13, 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 another router in a different domain as well as 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. "Advertising L2 Bundle Member Link Attributes in OSPF", Ketan Talaulikar, Peter Psenak, 2020-01-06, 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. "Industrial Use Cases for In-Network Computing", Ike Kunze, Klaus Wehrle, 2020-03-09, Cyber-physical systems and the Industrial Internet of Things are characterized by diverse sets of requirements which can hardly be satisfied using standard networking technology. One example are latency-critical computations which become increasingly complex and are consequently outsourced to more powerful cloud platforms for feasibility reasons. The intrinsic physical propagation delay to these remote sites can already be too high for given requirements. The challenge is to develop techniques that bring together these requirements. Utilizing available computational capabilities within the network for in-network computing concepts can be a solution to this challenge. This document discusses selected industrial use cases to demonstrate how in-network computing concepts can be applied to the industrial domain and to point out essential requirements of industrial applications. "RAW use cases", Georgios Papadopoulos, Pascal Thubert, Fabrice Theoleyre, Carlos Bernardos, 2020-03-08, The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases demanding reliable and available behavior. "Operations, Administration and Maintenance (OAM) features for RAW", Fabrice Theoleyre, Georgios Papadopoulos, Greg Mirsky, 2020-04-11, Some critical applications may use a wireless infrastructure. However, wireless networks exhibit a bandiwidth 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-05-03, 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). "OAM for use in GENEVE", Greg Mirsky, Xiao Min, Sami Boutros, David Black, Juniper Networks, 2020-03-09, This document defines encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol. Also, the format and operation of the Echo Request and Echo Reply mechanism in Geneve are defined. "BMP Extension for Path Marking TLV", Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf, 2020-03-09, 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 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-03-09, 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-03-09, 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 public key. Also, it provides proof of 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 Packet Network Slicing using Segment Routing", Yongqing Zhu, Ran Chen, Shaofu Peng, Fengwei Qin, 2019-12-03, [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 describes the IS-IS extensions required to support Packet Network Slicing using Segment Routing. "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu, 2020-04-30, 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-04-30, 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. "A method for dots server deployment", chenmeiling, Li Su, 2020-03-09, As DOTS is used for DDoS Mitigation signaling, in practice, there are different deployment scenarios for DOTS agents deployment depending on the network deployment mode. This document made an recommandation for DOTS Server deployment, include ISP and enterprise deployment scenarios. The goal is to provide some guidance for DOTS agents deployment. "CMP Updates", Hendrik Brockhaus, 2020-01-28, This document contains a set of updates to the base syntax of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue and the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities. "Usecases definition for IoT DDoS attacks prevention", Sorin Faibish, 2019-12-25, 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. "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng, Greg Mirsky, 2020-01-09, This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service. "BFD for Geneve", Xiao Min, Greg Mirsky, Juniper Networks, 2020-02-17, 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. "IoT Edge Challenges and Functions", Jungha Hong, Yong-Geun Hong, Xavier de Foy, Matthias Kovatsch, Eve Schooler, Dirk Kutscher, 2020-05-25, Many IoT applications have requirements that cannot be met by the traditional Cloud (aka Cloud computing). These include time sensitivity, data volume, uplink cost, operation in the face of intermittent services, privacy and security. As a result, the IoT is driving the Internet toward Edge computing. This document outlines the requirements of the emerging IoT Edge and its challenges. It presents a general model, and major components of the IoT Edge, with the goal to provide a common base for future discussions in T2TRG and other IETF WGs and RGs. "Intelligent Reasoning on External Events for Network Management", Pedro Martinez-Julia, Shunsuke Homma, 2020-03-06, The adoption of AI in network management solutions is becoming a reality. It is mainly supported by the need to resolve complex problems arisen from the acceptance of SDN/NFV technologies as well as network slicing. This allows current computer and network system infrastructures to constantly grow in complexity, in parallel to the demands of users. However, exploiting the possibilities of AI is not an easy task. There has been a lot of effort to make Machine Learning (ML) solutions reliable and acceptable but, at the same time, other mechanisms have been forgotten. It is the particular case of reasoning. Although it can provide enormous benefits to management solutions by, for example, inferring new knowledge and applying different kind of rules (e.g. logical) to choose from several actions, it has received little attention. While ML solutions work with data, so their only requirement from the network infrastructure is data retrieval, reasoning solutions work in collaboration to the network they are managing. This makes the challenges arisen from intelligent reasoning to be a key for the evolution of network management towards the full adoption of AI. "Hop-by-Hop Authentication in Content-Centric Networking/Named Data Networking", Ruidong Li, Hitoshi Asaeda, 2020-03-05, The unpredictability of consumers, routers, copyholders, and publishers for the in-network data retrievals in Content-Centric Networking (CCN) / Named Data Networking (NDN) poses a challenge to design an authentication mechanism to inhibit the malicious consumers to flood data requests and prevent the fake data from being provided. Signature is adopted as the fundamental function in CCN / NDN, which however can only provide publisher authentication with additional certificate acquisition. This document describes the Hop-by-Hop Authentication mechanism (HopAuth) integrating certificate collection and packet forwarding potentially with the assistance from certificate authority to provide consumer authentication, copyholder authentication and path authentication to enable the in-network data retrieval to be trustworthy, besides the publisher authentication. "Requirement of Computing in network", Peng Liu, Liang Geng, 2020-03-09, New technology such as IOT, edge computing,etc. propose the requirement of computing in network, so the convergence of network and computing has become a trend. It will bring some new directions and areas to be considered, such as the relationship between network and computing, the influence of integrating computing to the network, and so on. This document points out the requirements of computing in network according to the development of new Industry, including the network and computing requirements. "5G transport network benchmarking", Luis Contreras, Juan Rodriguez, Lourdes Luque, 2020-03-09, 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, 2020-01-27, 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. "Gateway Function for Network Slicing", Shunsuke Homma, Takayuki Nakamura, Xavier de Foy, A. Galis, Luis Contreras, Reza Rokui, Pedro Martinez-Julia, 2020-03-08, This document describes the roles and requirements for a slice gateway that is a function or function group for handling data plane traffic, such as connecting/disconnecting and compose/decompose network slice subnet instances and providing network slices from end to end. The interworking between management and control elements at the management and control planes with the gateway function for controlling and orchestrating end-to-end network slices are also presented in this document. "Protocol Assisted Protocol (PAP)", Zhenbin Li, Yunan Gu, 2020-03-06, 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. "Endpoint Taxonomy for CLESS", Mark McFadden, 2020-02-05, A separate document [I-D:draft-taddei-smart-cless-introduction] (CLESS) attempts to establish the capabilities and limitations of endpoint-only security solutions and explore potential alternative approaches. That document discusses endpoints in general terms. It has been suggested that there are classes of endpoints that have different characteristics. Those classes may have completely different threat landscapes and the endpoints may have completely different security capabilities. In support of the work on CLESS, this document provides a taxonomy of endpoints that is intended to provide a foundation for further work on CLESS and research on approaches to providing endpoint security alternatives in a diverse group of settings. "Encapsulation of Path Segment in SRv6", Cheng Li, Weiqiang Cheng, Zhenbin Li, Dhruv Dhody, 2020-03-03, Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of sub-paths, called "segments". Segment routing architecture can be implemented over IPv6 data plane, called SRv6. In some use-cases such as end-to-end SR Path Protection and Performance Measurement (PM), SRv6 path need to be identified. This document defines the encoding and processing of Path Segment in SRv6 networks. "Lightweight CMP Profile", Hendrik Brockhaus, Steffen Fries, David von Oheimb, 2020-01-28, The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2 and 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 uses 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 transactions are specified as mandatory. To foster interoperability also in more complex scenarios, other types of transactions are specified as recommended or optional. "Enhancement of IPv6 Extension Header", Zhenbin Li, Shuping Peng, Chongfeng Xie, Kihoon LEE, 2020-01-19, As SRv6 and the new services such as IOAM are progressing, more and more new requirements are imposed upon the IPv6 extension headers, i.e.. Hop-by-hop Options Header, Destination Options Header and Routing Header. This document defines new IPv6 extension headers and corresponding processing procedures considering the interactions among the existing IPv6 extension headers, SRH and the newly introduced IPv6 extension headers. "BGP Request for Candidate Paths of SR TE Policies", Zhenbin Li, Lei Li, Huaimo Chen, Yanhe Fan, Xufeng Liu, 2020-03-11, 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. "Application-aware IPv6 Networking", Zhenbin Li, Shuping Peng, Cong Li, Chongfeng Xie, 2020-04-19, A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some applications such as online gaming and live video streaming have very demanding network requirements thereof require special treatments in the network. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a finer granularity. Therefore, it is difficult to provide truly fine-granular traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware IPv6 Networking, and also the solution to guarantee SLA for applications, which makes use of IPv6 extensions header in order to convey the application related information including its requirements along with the packet to the network so to facilitate the service deployment and network resources adjustment. Then, it defines the application-aware options which can be used in the different IPv6 extension headers for the purpose. "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-05-19, 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 "BGP Usage for SDWAN Overlay Networks", Linda Dunbar, Jim Guichard, Ali Sajassi, John Drake, Basil Najem, David Carrel, 2020-04-28, The document describes three distinct SDWAN scenarios and discusses the applicability of BGP for each of those 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. "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", Fabio Peruzzini, Italo Busi, Daniel King, Sergio Belotti, Gabriele Galimberti, 2020-03-09, This document considers the applicability of the IETF Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI), and IP and Optical DWDM domain internetworking. In this document, we highlight the IETF protocols and YANG data models that may be used for the ACTN and control of POI networks, with particular focus on the interfaces between the MDSC (Multi- Domain Service Coordinator) and the underlying Packet and Optical Domain Controllers (P-PNC and O-PNC) to support POI use cases. "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane", Greg Mirsky, Mach Chen, David Black, 2020-03-23, This document defines the principals for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with IP data plane. "Return Routability Check for DTLS 1.2 and DTLS 1.3", Thomas Fossati, Hannes Tschofenig, 2020-03-02, This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. "DoH Preference Hints for HTTP", David Schinazi, Nick Sullivan, Jesse Kipp, 2020-01-08, When using a publicly available DNS-over-HTTPS (DoH) server, some clients may suffer poor performance when the authoritative DNS server is located far from the DoH server. For example, a publicly available DoH server provided by a Content Delivery Network (CDN) should be able to resolve names hosted by that CDN with good performance but might take longer to resolve names provided by other CDNs, or might provide suboptimal results if that CDN is using DNS- based load balancing and returns different address records depending or where the DNS query originated from. This document attempts to lessen these issues by allowing the web server to indicate to the client which DoH server can best resolve its addresses. This document defines an HTTP header field that enables web host operators to inform user agents of the preferred DoH servers to use for subsequent DNS lookups for the host's domain. "An Information Model for Claims used in RATS", Henk Birkholz, Michael Eckel, 2020-01-08, This document defines a standardized information model (IM) for Claims that can be used in remote attestation procedures (RATS). The information elements defined include attestation Claims which provide information about system components characteristics, as well as commonly used attributes and attribute structures that are required by protocols facilitating remote attestation. "Describing Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2020-04-24, 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-03-19, 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 } "HyStart++: Modified Slow Start for TCP", Praveen Balasubramanian, Yi Huang, Matt Olson, 2020-04-26, This informational memo describes HyStart++, a simple modification to the slow start phase of TCP congestion control algorithms. HyStart++ combines the use of one variant of HyStart and Limited Slow Start (LSS) to prevent overshooting of the ideal sending rate, while also mitigating poor performance which can result from false positives when HyStart is used alone. This memo also describes the details of the current implementation in the Windows operating system. "HTTP Transport Authentication", David Schinazi, 2020-03-13, 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-04-28, 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-01-21, 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-05-04, 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 used needs to meet a variety of requirements including being able to multiplex the traffic of multiple PDU sessions within a VLAN delineated access circuit, to permit legacy equipment in the data path to snoop certain packet fields, to carry 5G QoS information associated with the data, and to be efficiently encoded. This memo specifies an encapsulation that meets these requirements. "Compressed SRv6 Network Programming", Zhenbin Li, Cheng Li, Chongfeng Xie, Kihoon LEE, Hui Tian, Feng Zhao, Jim Guichard, Li Cong, Shuping Peng, 2020-02-25, Segment Routing can be applied to the IPv6 data plane by leveraging a new type of Routing Extension Header, called Segment Routing Header (SRH). However, the overhead introduced by SRH may be a challenge for existing hardware, which may influence on the forwarding performance and the payload efficiency. This document defines a compressed SRv6 network programming mechanism in order to reduce the overhead of SRv6 by introducing the Compressed Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH can be a new Routing Header or an enhancement of SRH. "Indication of Local DNS Privacy Service During User Access", Zhiwei Yan, Guanggang Geng, Yang Liu, 2020-01-20, This document aims to support the indication of privacy service of recursive resolver during the user access. "IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fengwei Qin, 2020-05-04, 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. "PCEP Extension for SR-MPLS Entropy Label Position", Shaofu Peng, Quan Xiong, Fengwei Qin, 2020-03-05, This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks. "TLS Authentication using ITS certificate", Mounira Msahli, Nancy Cam-Winget, William Whyte, Ahmed Serhrouchni, Houda Labiod, 2020-04-13, The IEEE and ETSI have specified a type of end-entity certificates. This document defines an experimental change to TLS to support IEEE/ ETSI certificate types to authenticate TLS entities. "Definition of new tags for relations between RFCs", Mirja Kuehlewind, Suresh Krishnan, 2020-03-09, 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, 2019-11-29, This document proposes a set of extensions for PCEP to support the constraints for network slicing during path computation, e.g, IGP instance, virtual network, specific application, color template and FA-id etc. "Version Capability for BGP", Donatas Abraitis, 2020-03-24, In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's version. "The "RRSERIAL" EDNS option for the SOA serial of a RR's zone", Hugo Salgado, 2020-01-27, The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS authoritative server to add a EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered resource record. This "RRSERIAL" data allows to debug problems and diagnosis by helping to recognize the origin of an answer, associating this answer with a respective zone version. "Evaluation of a Sample of RFC Produced in 2018", Christian Huitema, 2020-04-05, This document presents the author's effort to understand the delays involved in publishing an idea in the IETF, from the first individual draft to the publication of the RFC. We analyze a set of randomly chosen RFC approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFC published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH-48 phase. We also measure the number of citations of the chosen RFC using Semantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that. The RFCs selected for this survey were chosen at random and represent a small sample of all RFCs produced, and only approximately 10% of the RFCs produced in each of 1998, 2008, and 2018. It is possible that different samples would produce different results. Furthermore, the conclusions drawn from the observations made in this document represent the author's opinions and do not have consensus of the IETF. "Maintaining CCNx or NDN flow balance with highly variable data object sizes", David Oran, 2020-02-29, 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-02-23, 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. "Sampled Traffic Streaming", Andrew Gray, Lawrence Wobker, 2020-04-02, This document standardizes both 1) a means of requesting a stream of packet samples from any device generating, routing, or forwarding traffic, and 2) receiving metadata information from the network element about these packet samples, and the structure of said stream metadata. A main design requirement is to provide network elements with widely varying capabilities (e.g., ASICs, NPUs, NICs, vSwitches, CPUs) a mechanism to sample and export packets at high rates, by allowing communication of the specific bit formats of internal data headers applied to the packet flow, in a way that enhances interoperability between traffic sources and sinks. Historically, Netflow and similar mechanisms have been used for these use cases; however, the increasing packet rates of very high-speed devices and increasing variance in the information available to data planes lends itself to both a less-prescriptive set of packet formats as well as a decoupling of the sampling action from the collection and analysis mechanisms. "Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish, David Black, Philip Shilane, 2019-12-30, This document proposes extending NFSv4 operations to add new named 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 named 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. "MUD (D)TLS profiles for IoT devices", Tirumaleswar Reddy.K, Dan Wing, Blake Anderson, 2020-01-29, This memo extends Manufacturer Usage Description (MUD) to incorporate (D)TLS profile parameters. This allows a network element to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. "How Requests for IANA Action Will be Handled on the Independent Stream", Adrian Farrel, 2019-09-23, The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. The Independent Submissions Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE). This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submissions Stream that request actions from the IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. "YANG Data Model for OSPFv3 Segment Routing", Acee Lindem, Yingzhen Qu, 2020-02-05, 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 dataplane. "ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", Paul Yang, 2020-01-05, This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol version 1.3 to support ShangMi (SM) cryptographic algorithms. The use of these cipher suites with TLSv1.3 is not endorsed by the IETF. The SM cipher suites are becoming mandatory in China, and so this document provides a description of how to use the SM cipher suites with 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, 2019-12-12, 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. "URI Design and Ownership", Mark Nottingham, 2020-01-05, Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. "Packet Network Slicing using Segment Routing", Shaofu Peng, Ran Chen, Greg Mirsky, Fengwei Qin, 2020-02-19, 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. "OAuth 2.0 Client Intermediary Metadata", Aaron Parecki, 2020-05-08, This specification defines a mechanism for including information about additional parties involved in an OAuth transaction by adding a new section to the OAuth 2.0 Dynamic Client Registration request, as well as requires that authorization servers surface this information to users during an OAuth transaction. "YANG Data Model for Dynamic Flooding", Srinath Dontula, Tony Li, Athar Siddiqui, 2020-03-24, This document defines YANG data models that can be used to configure and manage Dynamic Flooding for IS-IS and OSPF. "RateLimit Header Fields for HTTP", Roberto Polli, Alejandro Ruiz, 2020-03-03, This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset header fields for HTTP, thus allowing servers to publish current request quotas and clients to shape their request policy and avoid being throttled out. "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael Richardson, 2020-05-03, This document specifies the behaviour of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings, 2020-05-05, 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. "Hierarchical HITs for HIPv2", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-05-13, This document describes using a hierarchical HIT to facilitate large deployments of managed devices. Hierarchical HITs differ from HIPv2 flat HITs by only using 64 bits for mapping the Host Identity, freeing 32 bits to bind in a hierarchy of Registering Entities that provide services to the consumers of hierarchical HITs. "Hierarchical HIT Registries", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-03-09, This document describes using the registration protocol and registries to support hierarchical HITs (HHITs). New and existing HIP parameters are used to communicate Registry Policies and data about the HHIT device and the Registries. Further Registries are expected to provide RVS services for registered HHIT devices. "New Cryptographic Algorithms for HIP", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-01-23, 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-03-19, This note extends LMS (RFC 8554) by defining parameter sets by including additional hash functions. Hese include hash functions that result in signatures with significantly smaller than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "A YANG Module for uCPE management.", Dmytro Shytyi, Laurent Beylier, Luigi Iannone, 2020-05-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. "BGP Flexible Color-Based Tunnel Selection", Yimin Shen, Ravi Singh, Yuji Kamite, 2020-02-03, This document discusses color-based tunnel selection for BGP payload prefixes. It defines a set of extended mapping modes, and describes how to use them to construct tunnel selection schemes for flexible tunnel selection. Tunnel selection schemes can be implemented as policies on routers performing tunnel selection, or signaled by next hop routers or a central controller by using the BGP extensions specified in this document. "SRv6 NET-PGM extension: Insertion", Clarence Filsfils, Pablo Camarillo, John Leddy, Daniel Voyer, Satoru Matsushima, Zhenbin Li, 2020-01-15, 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. "Area Proxy for IS-IS", Tony Li, Yunxia Chen, 2020-04-20, Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that would allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. "RADIUS Extensions for 0-RTT TCP Converters", Mohamed Boucadair, Christian Jacquenet, 2020-02-28, Because of the lack of important TCP extensions, e.g., Multipath TCP support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Transport Converters. For example, network-assisted Multipath TCP deployment models are designed to facilitate the adoption of Multipath TCP for the establishment of multi-path communications without making any assumption about the support of Multipath TCP by the remote servers. Transport Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of Multipath TCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters. "SR Replication Segment for Multi-point Service Delivery", Daniel Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2019-11-27, This document describes the SR Replication segment for multi-point service delivery. A SR Replication segment allows a packet to be replicated from a replication node to downstream nodes. "Segment Routing Point-to-Multipoint Policy", Daniel Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2020-04-13, This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE. "OpenPGP Example Keys and Certificates", Bjarni Einarsson, juga, Daniel Gillmor, 2019-12-20, The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. "Eliding and Querying RPL Information", Pascal Thubert, Rahul Jadhav, Li Zhao, Dominique Barthel, 2020-03-27, This document presents a method to safely elide a group of RPL options in a DIO message by synchronizing the state associated with each of these options between parent and child using a new sequence counter in DIO messages. A child that missed a DIO message with an update of any of those protected options detects it by the change of sequence counter and queries the update with a DIS Message. The draft also provides a method to fully elide the options in a DAO message. "IPv6 over Controller Area Network", Alexander Wachter, 2020-02-27, Controller Area Network (CAN) is a fieldbus initially designed for automotive applications. It is a multi-master bus with 11-bit or 29-bit frame identifiers. The CAN standard (ISO 11898 series) defines the physical and data-link layer. This document describes how to transfer IPv6 packets over CAN using ISO-TP, a dedicated addressing scheme, and IP header compression (IPHC). "Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security", Valery Smyslov, 2020-02-04, An IKEv2 extension defined in [I-D.ietf-ipsecme-qr-ikev2] 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. "Performance Measurement for Segment Routing Networks with MPLS Data Plane", Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Stefano Salsano, Mach Chen, 2020-03-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 Links and end-to-end SR Policies. In addition, this document defines Return Path TLV for two-way performance measurement and Block Number TLV for loss measurement. "MPLS Data Plane Encapsulation for In-situ OAM Data", Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak, 2020-03-17, 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 using the MPLS data plane encapsulation, including Segment Routing (SR) with MPLS data plane (SR-MPLS). "Using NETCONF Pub/Sub Model for RATS Interaction Procedures", Liang Xia, Wei Pan, 2020-02-27, This draft defines a new method of using the netconf pub/sub model in the RATS interaction procedure, to increase its flexibility, efficiency and scalability. "Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2020-04-23, 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. "Using QUIC Datagrams with HTTP/3", David Schinazi, 2020-04-16, 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. Discussion of this work is encouraged to happen on the QUIC IETF mailing list (quic@ietf.org [1]) or on the GitHub repository which contains the draft: . "EDX - Edge Exchanger", Sweta Jaiswal, Karthikeyan Arunachalam, Jamsheed Ppallan, Siva Dronamraju, Madhan Kanagarathinam, 2019-12-04, This document describes a new DNS resource record (RR) type, called the Edge Exchanger (EDX) RR, that is used to find services and location of the server(s) for any specific domain (the word domain is used here in the strict RFC1034 sense). "ACME for Subdomains", Owen Friel, Richard Barnes, Tim Hollebeek, Michael Richardson, 2020-03-06, This document outlines how ACME can be used by a client to obtain a certificate for a subdomain identifier from a certificate 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 authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay Hooda, 2020-05-02, 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, Zhibo Hu, 2019-12-08, This document describes the mechanism that can be used to announce the unreachable prefixes for service fast convergence. "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng, Greg Mirsky, 2020-01-03, 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-04-24, Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel (de)compression. 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). "Layer 3 Discovery and Liveness Signing", Randy Bush, Rob Austein, 2020-05-06, The Layer 3 Discovery and Liveness protocol OPEN PDU may contain a key and a certificate, which can be used to verify signatures on subsequent PDUs. This document describes two mechanisms based on digital signatures, one that is Trust On First Use (TOFU), and one that uses certificates to provide authentication as well as session integrity. "PEM file format for ECHO", Stephen Farrell, 2020-04-06, Encrypted ClientHello key pairs need to be configured into TLS servers, some of which can be built with different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these, similar to how RFC7468 defines other PEM file formats. "Stateless OpenPGP Command Line Interface", Daniel Gillmor, 2020-03-06, This document defines a generic stateless command-line interface for dealing with OpenPGP messages, known as "sop". It aims for a minimal, well-structured API covering OpenPGP object security. "The Computerate Specifying Paradigm", Marc Petit-Huguenin, 2020-03-09, 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. "Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms with the Internet X.509 Public Key Infrastructure", Dmitry Eremin-Solenikov, Vasily Nikolaev, Aleksandr Chelpanov, 2020-05-22, This document describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-2012 and GOST R 34.11-2012 for use in Internet X.509 Public Key Infrastructure (PKI). "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", Stanislav Smyshlyaev, Evgeny Alekseev, Smyshliaeva Ekaterina, Alexandra Babueva, 2019-12-16, 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-03-09, 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. "Integrity Protection for Network Service Header (NSH) and Encryption of Sensitive Context Headers", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, 2020-01-31, This specification adds integrity protection and optional encryption of sensitive metadata directly to Network Service Headers (NSH) used for Service Function Chaining (SFC). "Internet Services over ICN in 5G LAN Environments", Dirk Trossen, Chonggang Wang, Sebastian Robitzsch, Martin Reed, Mays AL-Naday, Janne Riihijarvi, 2020-02-04, 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-05-04, 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, 2020-02-21, 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. "Binary Structured HTTP Headers", Mark Nottingham, 2020-03-03, This specification defines a binary serialisation of Structured Headers for HTTP, along with a negotiation mechanism for its use in HTTP/2. It also defines how to use Structured Headers for many existing headers - thereby "backporting" them - when supported by two peers. "Overview and Principles of Internet Traffic Engineering", Adrian Farrel, 2020-05-13, This document describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are discussed throughout this document. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. "GOST XML digital signature syntax", Pavel Smirnov, Maria Paramonova, Mikhail Khomenko, Artyom Makarov, 2020-03-30, This document specifies XML digital signature syntax and methods of including hash-based message authentication code (HMAC) within the XML document to support the Russian cryptographic standard algorithms. "Architecture Discussion on SRv6 Mobile User plane", Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali, 2020-03-08, Layer separation is a powerful concept in system architecture. In the area of mobility, by separating GTP-U that is the overlay tunnel, and the IP transport network that is the underlay, the operation of the mobile network and the transport network can be separated, allowing them to evolve independently. However, evolving individually at each layer promotes local optimization and may result in non-optimal solutions overall in the long run. When a drastic architectural transition is required, for example, in the 5G era where various SLAs and completely new data intensive services are assumed, it is necessary to reconsider the architecture holistically, not from the viewpoint of individual part. One of important value propositions of SRv6 mobile user plane is to create overlay with underlay optimization. This document discusses the architecture implication of applying SRv6 mobile user plane. Then it takes 5G use cases as an example, and describes how these use cases are simply and effectively realized. Thus it shows that SRv6 mobile use plane is a right architectural choice for 5G era. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6", Xueshun Wang, Jinyou Dai, Jianhua Liu, Jing Xu, 2020-04-30, This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks. "Support for Enterprise-specific TLVs in the BGP Monitoring Protocol", Paolo Lucente, Yunan Gu, 2020-05-05, Message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data in TLV - Type, Length, Value - format; however the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. With this document we want to introduce an Enterprise Bit, or E-bit, for such purpose. "State-updating mechanism in RSVP-TE for MPLS network", Jun Gao, Jinyou Dai, 2020-04-30, 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. "Segment-Routing over Forwarding Adjacency Links", Tarek Saad, Vishnu Beeram, Colby Barth, Siva Sivabalan, 2020-02-09, Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) networks can be used to form Forwarding Adjacency (FA) links that carry traffic in those networks. An FA link can be assigned Traffic Engineering (TE) parameters that allow other LSR(s) to include it in their constrained path computation. FA link(s) can be also assigned Segment-Routing (SR) segments that enable the steering of traffic on to the associated FA link(s). The TE and SR attributes of an FA link can be advertised using known protocols that carry link state information. This document elaborates on the usage of FA link(s) and their attributes in SR enabled networks. "IETF Definition of Transport Slice", Reza Rokui, Shunsuke Homma, Kiran Makhijani, Luis Contreras, 2020-04-21, This document describes the definition of a slice in the transport networks and its characteristics. The purpose here is to bring clarity and a common understanding of the transport slice concept and describe related terms and their meaning. It explains how transport slices can be used in end to end network slices, or independently. "Bulk Subscription to YANG Event Notification", Zitao Wang, Qin WU, Peng Liu, Hui Cai, 2020-03-03, This document defines a YANG data model and associated mechanism that allows subscriber applications to bulk subscribe to publishers' event streams based on group identifier. This allows the publishers to report multiple notifications in a single bundling message. "IS-IS Flood Reflection", Tony Przygienda, Chris Bowers, Yiu Lee, Alankar Sharma, Russ White, 2020-01-07, 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 YANG Model Augmentations for Additional Features - Version 1", Acee Lindem, Stephane Litkowski, Yingzhen Qu, 2020-05-06, 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. "Color Operation with BGP Label Unicast", Louis Chan, 2020-04-16, 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 "Performance Measurement for Geneve", Xiao Min, Greg Mirsky, Juniper Networks, 2020-05-21, 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. "YANG Data Node Self Explanation Tags", Ran Tao, Qin WU, Benoit Claise, Liang Geng, Zongpeng Du, 2020-03-06, This document defines a method to tag data node associated with telemetry data in YANG Modules. This YANG data node tagging method can be used to 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 and provide multiple dimensional network visibility analysis when the state of all subscriptions of a particular Subscriber to be fetched is huge, so that the amount of data to be streamed out to the destination can be greatly reduced and only targeted to the characteristics data. An extension statement to be used to indicate YANG data node self explanation tags that SHOULD be added by the module implementation automatically (i.e., outside of configuration). A YANG module [RFC7950] is defined, which augments Module tag model and provides a list of data node entries to allow for adding or removing of data node self explanation tags as well as viewing the set of self explanation tags associated with a YANG module. "Self-explanation data Node tag capability", Ran Tao, Wu Bo, Peng Liu, Hui Cai, 2020-03-06, 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-explanation data Node tag capability which augments system capabilities model and provide additional self-explanation data node attributes associated with node selector within per-node capabilities. "A YANG Data Model for Client Signal Performance Monitoring", Haomian Zheng, Italo Busi, Zheng Yanlei, 2020-05-07, 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. The module carefully maps to relevant performance monitoring standards. "A Report on Compute First Networking (CFN) Field Trial", Shuheng Gu, Guanhua Zhuang, Huijuan Yao, Xunwen Li, 2019-12-01, Compute First Networking (CFN) enables the routing of the service request to an optimal edge site to improve the overall system load balancing and efficiency. Especially when an edge site is overloaded, other edges with service equivalency can dynamically serve the request. This document describes a CFN field trial to show the effect that CFN can achieve. Edge to edge interaction to get the available computing resources information for services and the network status to each other is introduced. Data plane to support late binding based dynamic anycast is illustrated too. The field trial shows that CFN can greatly improve the overall query per second served for a service hosted on multiple edges in a more balanced way. "BGP-LS Extensions for Segment Routing based Enhanced VPN", Jie Dong, Zhibo Hu, Zhenbin Li, 2020-03-09, Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require enhanced isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. To meet the requirement of enhanced VPN services, a number of Virtual Transport Networks (VTNs) need to be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific VPN+ service, or a group of VPN+ services. This document specifies the BGP-LS mechanisms with necessary extensions to advertise the information of Segment Routing (SR) based VTNs. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). "Context-Aware Navigator Protocol for IP-Based Vehicular Networks", Jaehoon Jeong, Bien Mugabarigira, Zhong Xiang, Yiwen Shen, 2020-05-07, This document proposes a Context-Aware Navigator Protocol (CAN) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CAN aims at the enhancement of driving safety through a light-weight driving information sharing method. The CAN 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-05-07, 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, 2020-04-15, 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-03-09, 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. "Resource Public Key Infrastructure (RPKI) Repository Requirements", Tim Bruijnzeels, Randy Bush, George Michaelson, 2020-04-25, This document formulates a plan of a phased transition to a state where RPKI repositories and Relying Party software performing RPKI Validation will use the RPKI Repository Delta Protocol (RRDP) [RFC8182] as the only mandatory to implement access protocol. In short this plan consists of the following phases. In phase 0, today's deployment, RRDP is supported by most, but not all Repositories, and most but not all RP software. In the proposed phase 1 RRDP will become mandatory to implement for Repositories, in addition to rsync. This phase can start as soon as this document is published. Once the proposed updates are implemented by all Repositories phase 2 will start. In this phase RRDP will become mandatory to implement for all RP software, and rsync must no longer be used. Measurements will need to be done to help determine when it will be safe to transition to the final phase of this plan. During this phase Repositories will no longer be required to provide rsync access for RPKI validation purposes. However, they may still provide rsync access for direct access to files for other purposes, if desired, at a best effort basis. Although this document currently includes descriptions and updates to RFCs for each of these phases, we may find that it will be beneficial to have separate documents for the plan, and each phase, so that it might be more clear to all when the updates to RFCs take effect. "An Alternative Delta Time encoding for CCNx using Interval Time from RFC5497", Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch, 2020-03-09, 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 RFC5497. This document updates _CCNx messages in TLV Format_ (RFC8609) to specify this alternative encoding. "Service Assurance for Intent-based Networking Architecture", Benoit Claise, Jean Quilbeuf, Youssef El Fathi, Diego Lopez, Daniel Voyer, 2020-03-09, 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. "IETF Stream Documents Require IETF Rough Consensus", Joel Halpern, Eric Rescorla, 2020-03-05, This document proposes that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026. "Communicating Warning Information in HTTP APIs", Andre Cedik, Erik Wilde, 2020-03-30, This document defines a new HTTP header 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 (). "Selecting Resolvers from a Set of Distributed DNS Resolvers", Jari Arkko, Martin Thomson, Ted Hardie, 2020-03-09, This memo discusses the use of a set of different DNS resolvers to reduce privacy problems related to resolvers learning the Internet usage patterns of their clients. "Discovery Mechanism for QUIC-based, Non-transparent Proxy Services", Mirja Kuehlewind, Zaheduzzaman Sarker, 2020-01-27, 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 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. "Challenges and Changes in the Internet Threat Model", Jari Arkko, Stephen Farrell, 2020-03-09, 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. "Transport Protocol Issues of In-Network Computing Systems", Ike Kunze, Klaus Wehrle, 2020-03-09, 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 discusses selected characteristics of transport protocols which have to be adapted to support COIN functionality. "Considerations for defining a Transport Slice NBI", Luis Contreras, Shunsuke Homma, Jose Ordonez-Lucena, 2020-03-09, 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 transport slice consumers in order to identify the functionality required on the North Bound Interface (NBI) of a transport slice controller for satisfying such transport slice requests. "IS-IS Flooding Scale Considerations", Les Ginsberg, Peter Psenak, Acee Lindem, Tony Przygienda, 2020-04-17, 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. "Protected Headers for Cryptographic E-mail", Bjarni Einarsson, juga, Daniel Gillmor, 2019-12-20, This document describes a common strategy to extend the end-to-end cryptographic protections provided by PGP/MIME, etc. to protect message headers in addition to message bodies. In addition to protecting the authenticity and integrity of headers via signatures, it also describes how to preserve the confidentiality of the Subject header. "IGMPv3/MLDv2 Message Extension", Mahesh Sivakumar, Stig Venaas, Zheng Zhang, 2020-03-06, IGMP and MLD protocols are extensible, but no extensions have been defined so far. This document provides a well-defined way of extending IGMP and MLD, including a new extension type to distinguish between different extensions. "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini, Klaus Hartke, 2020-03-09, 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. "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-03-09, 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. "Tunneling Internet protocols inside QUIC", Maxime Piraux, Olivier Bonaventure, 2020-03-09, This document specifies methods for tunneling Ethernet frames and Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection. "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John Mattsson, Francesca Palombini, 2020-03-09, 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 footprint can be kept very low. "The OAuth 2.0 Authorization Framework: Claims", Travis Spencer, 2019-11-23, This document extends the OAuth 2.0 framework to include a simple query language that can be used by clients to request certain claims from an authorization server. This mechanism can be used during the authorization request and refresh request. It also defines a response parameter of the token and introspection endpoints that indicates to the caller which claims were authorized by the resource owner. Lastly, it stipulates how this request parameter can be used during token exchange, and how clients may request that certain claims be placed in an access token intended for a particular resource server. "YANG Modules for Service Assurance", Benoit Claise, Jean Quilbeuf, Paolo Lucente, Paolo Fasano, 2020-02-19, 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-03-09, 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. "Top-level Domains for Private Internets", Roy Arends, Ed Lewis, 2020-05-02, 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. "Publish/Subscribe over the Constrained Application Protocol (CoAP) using the Constrained RESTful Application Language (CoRAL)", Klaus Hartke, 2020-05-09, This document explores how the Constrained RESTful Application Language (CoRAL) might be used for enabling publish/subscribe-style communication over the Constrained Application Protocol (CoAP), which allows CoAP nodes with long breaks in connectivity and/or up-time to exchange data via a publish/subscribe broker. "TLS Proxy Best Practice", Eric Wang, Andrew Ossipov, Roelof DuToit, 2020-03-04, TLS proxies are widely deployed by organizations to enable security features and apply enterprise policies. This document defines a TLS proxy and discusses a wide range of security requirements to guide TLS proxy implementations. "Bijective MAC for Constraint Nodes", Pascal Urien, 2019-12-12, 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. "Personal Information Tagging for Logs", Sandeep Rao, Santhosh N, Shivan Sahib, Ryan Guest, 2020-03-09, Software systems typically generate log messages in the course of their operation. These log messages (or 'logs') record events as they happen, thus providing a trail that can be used to understand the state of the system and help with troubleshooting issues. Given that logs try to capture state that is useful for monitoring and debugging, they can contain information that can be used to identify users. Personal data identification and anonymization in logs is crucial to ensure that no personal data is being inadvertently logged and retained which would make the logging system run afoul of laws around storing private information. This document focuses on exploring mechanisms that can be used by a generating or intermediary logging service to specify personal or sensitive data in log message(s), thus allowing a downstream logging server to potentially enforce any redaction or transformation. "SIP Call-Info Parameters for Rich Call Data", Chris Wendt, Jon Peterson, 2020-03-09, This document describes a SIP Call-Info usage defined to include rich data associated with the identity of the calling party that can be rendered to called party for providing more useful information about the caller or the specific reason for the call. This includes extended comprehensive information about the caller such as what a jCard object can represent for describing the calling party or other call specific information such as describing the reason or intent of the call. The elements defined for this purpose are intended to be extensible to accommodate related information about calls that helps people decide whether to pick up the phone and additionally, with the use of jCard and other elements, to be compatible with the STIR/ PASSporT Rich Call Data framework. "The DANE Authentication Chain Extension for TLS", Viktor Dukhovni, Shumon Huque, Willem Toorop, Paul Wouters, Melinda Shore, 2019-12-17, This draft describes a new TLS extension for in-band transport of the complete set of DNSSEC validated records needed to perform DANE authentication of a TLS server without the need to perform separate out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a validated denial of existence proof. "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Ralph Dolmans, 2020-03-09, 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. "User Plane Message Encoding", Tetsuya Murakami, Satoru Matsushima, Kentaro Ebisawa, Pablo Camarillo, Ravi Shekhar, 2020-03-06, This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network. "L-band Digital Aeronautical Communications System (LDACS)", Nils Maeurer, Thomas Graeupl, Corinna Schmitt, 2020-04-01, This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation. LDACS is a scheduled, reliable multi-application cellular broadband system with support for IPv6. "Deadline-aware Transport Protocol", Yong Cui, Zhiwen Liu, Hang Shi, Jie Zhang, Kai Zheng, Wei Wang, 2020-01-20, 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-05-15, 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. "CBOR Object Signing and Encryption (COSE): Additional Algorithms", Jim Schaad, 2020-05-22, The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional algorithms to the registries. This document adds one additional key wrap algorithm to the registry using the AES Wrap with Padding Algorithm [RFC5649]. This document adds Keccak Message Authentication Code (KMAC) algorithms as well as using KMAC as a Key Derivation Function (KDF). "National Identifier Top-level Node Interface Protocol", Yuying Chen, Jiagui Xie, Zhiping Li, Hongyan Liu, 2020-05-07, 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. "The Transport-Info HTTP Header", Piers O'Hanlon, James Gruessing, 2020-03-03, The Transport-Info header provides a mechanism to transmit network transport related information such as current delivery rate and round-trip time, from a server or a client. This information has a wide range of uses such as client monitoring and diagnostics, or allowing a client to adapt to current network conditions. 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/bbc/draft-ohanlon-transport-info-header [1]. "Braid-HTTP: Synchronization for HTTP", Michael Toomim, Greg Little, Rafie Walker, Bryn Bellomy, 2020-03-09, Braid is a set of extensions that generalize HTTP from a state *transfer* protocol into a state *synchronization* protocol. Braid puts the power of Operational Transform and CRDTs on the web, improving network performance and enabling natively peer-to-peer, collaboratively-editable, offline-first web applications. Braid is composed of four extensions to HTTP: "S/MIME Example Keys and Certificates", Daniel Gillmor, 2019-12-24, The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. "A YANG Model for User-Network Interface (UNI) Topologies", Oscar de Dios, Samier Barguil, Qin WU, Mohamed Boucadair, 2020-04-02, This document defines a YANG data model for representing an abstract view of the Service Provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, SDWAN). The data model augments the 'ietf-network' data model by adding the concept of service-attachment-points. The service- attachment-points are an abstraction of the points to which network services (such as L3 VPN or L2 VPN) can be attached. "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-04-10, 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. "Partial Uploads in HTTP", Austin Wright, 2019-12-05, This document specifies a new media type intended for use in PATCH payloads that allows a resource to be uploaded in several segments, instead of a single large request. "A Security Architecture Against Service Function Chaining Threats", THANG Nguyen, Minho Park, 2019-11-24, Service Function Chaining (SFC) provides a special capability that defines an ordered list of network services as a virtual chain and makes a network more flexible and manageable. However, SFC is vulnerable to various attacks caused by compromised switches, especially the middlebox-bypass attack. In this document, we propose a security architecture that can detect not only middlebox-bypass attacks but also other incorrect forwarding actions by compromised switches. The existing solutions to protect SFC against compromised switches and middlebox-bypass attacks can only solve individual problems. The proposed architecture uses both probe-based and statistics-based methods to check the probe packets with random pre- assigned keys and collect statistics from middleboxes for detecting any abnormal actions in SFC. "Network Address Translation Support for QUIC", Martin Duke, 2020-03-09, 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. "SMTP Extension for Longer Email Address", Viruthagiri Thirumavalavan, 2019-12-04, This memo defines an SMTP extension with keyword "EAML" whereby an SMTP server can declare that it is capable of handling longer email addresses without any local-part or domain-part restriction set by RFC 5321. EAML stands for "Email Address Maximum Length". "Data Aggregation in IPv6-based Vehicular Networks", Zhiwei Yan, Jong-Hyouk Lee, Jaehoon Jeong, Yong-Jin Park, Hidenori Nakazato, 2020-05-17, 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. "LSP Object Flag Extension of Stateful PCE", Quan Xiong, 2019-12-04, RFC8231 describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. One of the extensions is the LSP object which includes a Flag field and the length is 12 bits. However, 11 bits of the Flag field has been assigned in RFC8231, RFC8281 and RFC8623 respectively. This document proposes to define a new LSP-EXTENDED-FLAG TLV for LSP object to extend the length of the flags. "The Base58 Encoding Scheme", Satoshi Nakamoto, Manu Sporny, 2019-11-27, 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-03-09, 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 satisfy network slicing scenarios. "Delivering Functions over Networks: Traffic and Performance Optimization for Edge Computing using ALTO", Shu Yang, Laizhong Cui, Mingwei Xu, Hongfei Shen, Lu Chen, 2019-11-29, With development of Internet of Thing (IoT), artificial intelligence, huge amount of data are generated and need to be processed. To satisfy the user demands, service providers are deploying edge computing across lots of data centers, which are closer to users. In order to achieve better performances, computing functions need to be scheduled properly over networks. However, it is challenging to deploy functions to the distributed edge servers efficiently due to the lack of network traffic information. [RFC5693] and [RFC7285] introduce and define the Application-Layer Traffic Optimization, or ALTO, to compute and provide the network information for the distributed applications using the ALTO protocol. In this document, we employ the ALTO protocol to deliver functions in edge computing platform, where the protocol will provide the network information for the distributed edge computing servers and guide the delivery process. The usage of ALTO will improve the efficiency of function delivering in edge computing. "EVPN ALL-ACTIVE ANYCAST DETECTION", Haibo Wang, 2019-11-30, A principal feature of EVPN is the ability to support universal detection including ping/trace, twamp, 2544, 1564 and so on. This draft specifies a mechanism of valid universal detection in all- active anycast scenes based on connectivity negotiations to avoid detection interruption due to the inconsistency between the request packet path and the response packet path. "Operational Considerations for BRSKI Registrar", Michael Richardson, 2020-03-09, 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. "IMAP4 INBOXES extension", Ben van Hartingsveldt, 2019-12-02, The INBOXES extension to the Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) protocol gives the client the possibility to manage multiple inboxes (mail addresses) with the same username and password. Without this extension you only have access to one inbox. "Coordinate-Based Dynamic IPv6 Multicast Addresses Allocation", Haihong Zhang, 2019-12-02, This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for coordinate-based allocation of IPv6 multicast addresses. "Simple Mail Transfer Protocol", John Klensin, 2019-12-27, 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. "Operational Considerations for Manufacturer Authorized Signing Authority", Michael Richardson, Wei Pan, 2020-03-09, This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. "SCHC over PPP", Pascal Thubert, 2019-12-03, 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. "Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)", Laura Corcoran, Michael Jenkins, 2019-12-04, 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. "IPv6 over Link-Local Discovery Protocol", Michael Richardson, Liang Xia, 2020-04-07, This document describes a mechanism to encapsulate IPv6 packets over the Link Layer Discovery Protocol (LLDP). The LLDP is a single layer-two protocol with its own ethertype. It is never forwarded, which is a desireable property when building the IPv6-over-IPsec- over-IPv6-Link-Local tunnels that make up the ANIMA Autonomic Control Plane (ACP). This unorthodox encapsulation avoids unwanted interactions between the ACP packets and native packet forwarding engines, as well as being safe for layer-2 switches which might otherwise have no IPv6 capabilities. "A Layer 2 VPN Network Yang Model", Samier Barguil, Oscar de Dios, Victor Lopezalvarez, Luis Munoz, Luay Jalil, 2020-03-09, 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 L2SM complements the Layer 2 Service Model (RFC8466) by providing a network-centric view of the service that is internal to a Service Provider. "RTP Payload Format for Essential Video Coding (EVC)", Shuai Zhao, Stephan Wenger, 2020-03-11, 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. "An IPv6 Air/Ground Interface for the International Civil Aviation Organization (Use Case)", Fred Templin, 2019-12-10, The International Civil Aviation Organization (ICAO) is building a worldwide IPv6-based Air Traffic Management (ATM) service known as the Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). Aircraft connect to the ATN/IPS via an IPv6 Air/ Ground (A/G) interface that provides a nexus for control and data messages exchanges over all available aviation wireless data links. This document discusses the use case that motivates a new IPv6 interface abstraction. "Using cSHAKE in ORCHIDs", Robert Moskowitz, Stuart Card, Adam Wiethuechter, 2020-05-21, This document specifies how to use the cSHAKE hash for ORCHID generation and allows for varying sized hashes in the ORCHID along with additional information within the ORCHID. It is an addendum to ORCHIDv2 [RFC7343]. "Internet Message Format", Pete Resnick, 2019-12-11, 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. "Internationalization for the NFSv4 Protocols", David Noveck, 2020-03-09, 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, 2019-12-16, This document defines an IPv6 Hop-by-Hop Option that provides attribution for IPv6 extension headers inserted by intermediate nodes in the delivery path of a packet. The purpose of this option is twofold: first it identifies the extension headers that have been inserted, secondly it attributes the inserted extension headers to the node responsible for inserting them. "Deterministic ECDSA and EdDSA Signatures with Additional Randomness", John Mattsson, Erik Thormarker, Sini Ruohomaa, 2020-03-11, Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security do not depend on a source of high-quality randomness. Recent research has however found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their determinism. One countermeasure to such attacks is to re-add randomness to the otherwise deterministic calculation of the per-message secret number. This document updates RFC 6979 and RFC 8032 to recommend constructions with additional randomness for deployments where side-channel attacks and fault injection attacks are a concern. "TLS Ticket Request Message", Raja K, 2020-04-13, TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve new session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. "JSON Web Message", Tobias Looker, 2020-01-14, JSON Web Message (JWM) is a flexible way to encode application-level messages in JSON for transfer over a variety of transport protocols. JWMs use JSON Web Encryption (JWE) to protect integrity, achieve confidentiality, and achieve repudiable authentication; alternatively or in addition, they use JSON Web Signatures (JWS) to associate messages with a non-repudiable digital signature. "AutoAdd - Automatic Bootstrapping of IoT Devices", Anoop Pandey, 2019-12-22, IoT devices are fast getting embedded into our lives, and when put together they have the potential to generate a precise and detailed history of our lives and store them forever. Their networking and communicational power can be unleashed for malicious and sabotage purposes, by a motivated attacker sitting in the far corner of the world. Attacks on Industrial IoT systems can cause greater disasters. It is therefore essential to inculcate the security aspect, right from design to development to operations. The first operation of an IoT device is to bootstrap itself, and due importance should be placed to ensure that this operation is carried out securely and with due diligence. However, it's easier said than done, and this paper outlines several approaches for secure automated bootstrapping and also proposes a new method, which is compared against the existing mechanisms for several qualitative factors. "RPKI validated cache Update in SLURM over HTTPs (RUSH)", Di Ma, Hanbing Yan, 2019-12-24, 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, 2019-12-25, This document specifies the format, contents and semantics of data escrow deposits for Industrial Internet Identifier Second-level Node (SLN). SLN directly serves enterprises and provides services such as identifier registration, identifier resolution, data sharing, etc. The mapping objects in this document mainly refers to the enterprise registration information of the SLN and the Enterprise-level Node (ELN) registered in the SLN. "Abstract", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2019-12-25, This document specifies the format and contents of data escrow deposits targeted primarily for Industrial Internet Identifier Node (IIIN) which provides identifier registration. However, this specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than IIIN. "HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2020-01-16, This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System (BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS). Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management. "Security Services for the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2020-01-16, The Industrial Internet Identifier Data Access Protocol (IIIDAP) provides "RESTful" web services to retrieve identifier metadata from Second-Level Node (SLN). This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for IIIDAP. "JSON Responses for the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, 2020-01-16, This document describes JSON data structures representing identifier information maintained by Second-Level Nodes (SLN). These data structures are used to form Industrial Internet Identifier Data Access Protocol (IIIDAP) query responses. "Finding the Authoritative Registration Data (IIIDAP) Service", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2020-01-16, This document specifies a method to find which Industrial Internet Identifier Data Access Protocol (IIIDAP) server is authoritative to answer queries for a request of identifier data. "Industrial Internet Identifier Data Access Protocol (IIIDAP) Query Format", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2020-01-16, This document describes uniform patterns to construct HTTP URLs that may be used to retrieve identifier information from Second-Level Nodes (SLN) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Industrial Internet Identifier Data Access Protocol (IIIDAP). "HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2019-12-26, 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. "IGP Flexible Algorithm with L2bundles", Shaofu Peng, Ran Chen, Greg Mirsky, 2020-03-29, 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-01-09, 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, 2019-12-30, 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. "Hierarchically Located Addressing and Routing Protocol", anonymous, 2020-01-02, This internet-draft describes a protocol with an addressing scheme where members of the internet are addressed by their physical addresses and by an implementing internet router that can contact them. The packets sent by the protocol include handshake messages, client data, and the status of the data being sent. A routing procedure is suggested according to special addresses that carry information about the region of a router. "CoAP Application version of Resource Directory", Jim Schaad, 2020-01-03, This is a draft of what I think a CoRE Application should look like. "Inter-domain Network Slicing via BGP-LU", Jin Zhou, Chunning Dai, Shaofu Peng, 2020-02-18, 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, 2020-03-09, 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, 2020-03-09, 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, Liang Xia, 2020-03-09, 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). "CPace, a balanced composable PAKE", Bjoern Haase, 2020-02-07, 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. "BGP SR Policy Extensions to Enable IFIT", Fengwei Qin, Hang Yuan, Tianran Zhou, Liu Min, Giuseppe Fioccola, 2020-01-07, 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) provides a reference framework that supports network OAM applications to apply dataplane on-path telemetry techniques acquiring data about a packet on its forwarding path. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT behavior can be enabled automatically when the SR policy is applied. "PCEP SR Policy Extensions to Enable IFIT", Huanan Chen, Hang Yuan, Tianran Zhou, Weidong Li, Giuseppe Fioccola, 2020-01-07, 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) provides a reference framework that supports network OAM applications to apply dataplane on-path telemetry techniques acquiring data about a packet on its forwarding path. This document defines extensions to PCEP to distribute SR policies carrying IFIT information. So that IFIT behavior can be enabled automatically when the SR policy is applied. "OSPF Graceful Restart Enhancements", Sami Boutros, Ankur Dubey, Vijayalaxmi Basavaraj, Acee Lindem, 2020-01-07, 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. "SIPv6 Headers and SDP Media Line Address Selection on Multihomed Hosts", Dusan Mudric, Dragan Grebovich, 2020-01-08, In the networks where multihomed hosts can have ULA and GUA addresses from different ISPs, multiple SIP signaling and media connectivity issues might arise due to inappropriate address selections. Some of the problems are described in [RFC5220]. Since SIP and SDP allow IP addresses to be embedded into their headers and lines, even if proper addresses are selected initially, SIP is not equipped with the mechanisms to respond to network events, and transition transport to reachable addresses. As a result, SIP messages and media might be filtered by routers, or discarded as unreachable destinations. SIP protocol (RFC 3261) defines signaling messages and their headers. This document describes how a multihomed host should select addresses for SIP headers, like Contact and Via, to be reachable destinations. Host SHOULD change a default router for uplink failures, remove prefixes and addresses for unreachable ISP, and update contact address list. SDP protocol (RFC 3264) defines how participants in a session select their parameters. This document describes how an offerer and answerer on multihomed hosts should select their addresses. If one of the selected addresses becomes unreachable, the document describes the mechanism how a new one should be selected and renegotiated. "MASQUE Obfuscation", David Schinazi, 2020-03-13, 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 (mailto:masque@ietf.org) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts (https://github.com/DavidSchinazi/masque-drafts). "Passive Interface Attribute", Aijun Wang, Zhibo Hu, 2020-01-09, This document describes the mechanism that can be used to differentiate the passive interfaces from the normal interfaces within ISIS domain. "In-band Network Telemetry for 6TiSCH Networks", Abdulkadir Karaagac, Jeroen Hoebeke, 2020-01-11, This document describes In-band Network Telemetry for 6TiSCH Networks, offering a flexible monitoring solution with minimal resource consumption and communication overhead while supporting a wide range of monitoring operations and strategies for dealing with various network scenarios and use cases. It enables 6TiSCH networks to collect per-packet and per-hop monitoring information by piggybacking telemetry information onto the data packets by exploiting the remaining space in the IEEE 802.15.4e frames, thus not impacting network behavior and performance. This document also discusses the data fields and associated data types for 6TiSCH INT mechanism. "Use of Static-Static ECDH in JSON Object Signing and Encryption (JOSE)", Guillaume Amringer, 2020-01-11, This document defines how to use the Static-Static mode of ECDH in JSON Object Signing and Encryption (JOSE). "(strong) AuCPace, an augmented PAKE", Bjoern Haase, 2020-02-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. "GPS Over WiFi.", Rob Brew, 2020-01-14, When users are at known underground locations, such as tube stations they often do not have a GPS signal, as the radio waves from the satellites required cannot penetrate the earth, this draft suggests providing GPS locations over WiFI using remote IP detection for a server to respond with the correct name of clients location and the clients GPS location.IP address. Extending this to those without WiFI access the standard goes one stage further, by offering a hidden WiFI network with a standard name, such as .location. The principle being that mobile devices can look for this network in cases where GPS data cannot be collected. It is hoped that this will allow those using mapping services to know where they are when travelling on underground trains etc. "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Dmitry Belyavsky, Vasily Dolmatov, 2020-03-10, 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). "Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications", Brian Campbell, 2020-05-07, This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner. "IGP Extensions for Segment Routing Service Segment", Liu Yao, Zheng Zhang, 2020-02-24, This document defines extensions to the link-state routing protocols (IS-IS and OSPF) in order to carry service segment information via IGP. "Applications and Use Cases for the Quantum Internet", Chonggang Wang, Akbar Rahman, Ruidong Li, Melchior Aelmans, 2020-05-05, The Quantum Internet has the potential to improve Internet application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. In this document, we provide an overview of some applications expected to be used on the Quantum Internet, and then categorize them using various classification schemes. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to provide a common understanding and framework of applications and use cases for the Quantum Internet. "Context Label for MPLS EVPN", Yubao Wang, 2020-01-17, 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 only connect to each other by the hub PE. MPLS EVPN can't support AR REPLICATOR. MPLS EVPN can't support anycast SR-MPLS tunnel on the SPE nodes. This document introduces a compound label stack to take advantage of both P2P VC and MP2P evpn labels. "Analysis Framework For Extensions of SRv6 Encapsulation", Clarence Filsfils, Darren Dukes, Keyur Patel, 2020-01-17, 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, 2020-01-17, This document defines a stateless and scalable solution to achieve network slicing with SRv6. "The LoST-Validation S-NAPTR Application Service Tag", Randall Gellens, Brian Rosen, 2020-05-20, This document adds the "LoST-Validation" service tag to the Straightforward Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation Protocol (LoST) in identifying LoST servers explicitly willing to perform location validation. This tag and the information on its use is an update to RFC5222 that enables the explicit discovery of a server that supports location validation. "SRv6 vSID: Network Programming extension for variable length SIDs", Bruno Decraene, Robert Raszuk, Zhenbin Li, Cheng Li, 2020-03-09, 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, 2020-01-21, This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement URLs for a device. "BGP-LS Extensions for Transport Slice", Ran Chen, 2020-01-21, [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. "Publishing Information for Entities Identified by Domain Names", Martin Hoffmann, 2020-01-22, This memo describes a mechanism to publish information related to an entity identified through a domain name via the Domain Name System (DNS). In particular, this mechanism allows publishing the location of topical documents describing the entity and relationships with other entities. An example application is the publishing of additional requirements for PKI certification authorities. "ISIS Extension to Support Network Slicing over IPv6 Dataplane", Shaofu Peng, Ran Chen, Greg Mirsky, 2020-01-22, [I-D.peng-teas-network-slicing] defines an unified TN-slice identifier, i.e., AII(administrative instance identifier) and related processing combined with Segment Routing technology, for the purpose of unified identification of topology, computing, storage resources, unified partition of L2 and L3 link resources, unified basis of underlay path selection within or between domains, and unified flow steering rule with SR policy color scheme. This document describes the ISIS extensions required to support Packet Network Slicing over IPv6 dataplane. "Registration Data Access Protocol (RDAP) Query Format", Scott Hollenbeck, Andrew Newton, 2020-05-08, This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). "HTTP Resources with User Names", Rick van Rein, 2020-02-03, Many protocols support users under domain names, but HTTP does not. This specification defines a header for user names, independent of authenticated identities, and a link to userinfo in HTTP URIs. This intergrates naturally with HTTP, and results in a more refined resource authentication model, in support of advanced usage scenarios. "DNS over Foo Discovery Mechanism", Daniel Migault, 2020-01-23, This document describes a mechanism that enables a DNS client to discover other DNS alternatives such as DoT or DoH for one specific domain. This document also extends this discovery mechanism to an Internet wide of open resolvers search - though this is expected to be described further in a separate document. While search are always initiated by the DNS client, this document also indicates how a resolver MAY indicate a DNS client its preference for using alternative flavors of transport layer. "Sender Control of Acknowledgement Delays in QUIC", Jana Iyengar, Ian Swett, 2020-01-23, 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 . "Privacy issues in Identifier/Locator Separation Systems", Luigi Iannone, Dirk Hugo, Behcet Sarikaya, Erik Nordmark, 2020-03-09, There exists several protocols and proposals that leverage on the Identifier/Locator split paradigm, having some form of control plane by which participating nodes can share their current Identifier-to- Location information with their peers. This document explores some of the privacy considerations for such a type of system. "BGP based Virtual Private Network (VPN) Services over SRm6 enabled IPv6 networks", Srihari Ramachandra, Ron Bonica, 2020-03-09, 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-03-24, 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. "VLSM Tree Routing Protocol", Shyam Bandyopadhyay, 2020-01-29, This is a light weight routing protocol applicable inside a network that appears in the form of a tree and distribution of address space takes place with the approach of VLSM. It is based on setting default route inside VLSM tree. With this approach, routing information of the external world need not be passed down to the VLSM tree. Thus, load inside a router gets reduced substantially. This document includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. "Host Identification with Provider Independent Address", Shyam Bandyopadhyay, 2020-01-29, This is a protocol to identify a host with a provider independent address. It is useful to identify a host uniquely in a multihomed environment where each host gets associated with more than one provider assigned addresses. By means of associating a host with a provider independent address, customers/customer networks will be able to retain their number even after changing their service provider(s). "The XAuth Protocol", Dick Hardt, 2020-03-22, 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 can be extended to support alternative authorizations, claims, interactions, and client authentication mechanisms. "Gated Adaptive CoDel for Time-Sensitive Network", Jaehwoon Lee, Chongho Yoon, 2020-01-30, This draft proposes a gated adaptive CoDel algorithm that can operate in the Time-Sensitive Network (TSN) environment. Here, we define Virtual sojourn time, virtual Interval and virtaul Target that are only operate on non-blocking part of TSN. "Point-to-Multipoint Transport Using Chain Replication in Segment Routing", Yimin Shen, Zhaohui Zhang, Rishabh Parekh, Hooman Bidgoli, Yuji Kamite, 2020-04-01, 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. "Data Center Fast Congestion Management", Roni Even, Mengzhu Liu, Yali Zhang, 2020-02-04, A good congestion control for data centers (DC) should provide low latency, fast convergence and high link utilization. Since multiple applications with different requirements may run on the DC network it is important to provide fairness between different applications that may use different congestion algorithms. An important issue from the user perspective is to achieve short Flow Completion Time (FCT). This document proposes data center congestion control direction aiming to achieve high performance while proving fairness. "Lightweight Authorization for Authenticated Key Exchange.", Goeran Selander, John Mattsson, Malisa Vucinic, Michael Richardson, Aurelio Schellenbaum, 2020-03-09, This document describes a procedure for augmenting an authenticated Diffie-Hellman key exchange 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-02-28, 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). "RealTime Internet Peering for Telephony", Jonathan Rosenberg, Cullen Jennings, Anthony Minessale, Jason Livingood, Justin Uberti, 2020-02-07, This document specifies the Realtime Internet Peering for Telephony (RIPT) protocol. RIPT is used to provide peering of voice and video communications between entities. These include a traditional voice trunking provider (such as a telco), and a trunking consumer (such as an enterprise PBX or contact center), or between a video conferencing endpoint deployed in an enterprise, and a video conferencing SaaS service. RIPT is an alternative to SIP, SDP and RTP for these use cases, and is designed as a web application using HTTP/3. Using HTTP/3 allows implementors to build their applications on top of cloud platforms, such as AWS, Azure and Google Cloud, all of which are heavily focused on HTTP based services. RIPT also addresses many of the challenges of traditional SIP-based peering. It supports modern techniques for load balancing, autoscaling, call-preserving failover, graceful call migrations, security by default, STIR-based caller ID, provisioning, and capabilities - all of which have been challenges with traditional SIP peering and voice trunking. Since it runs over HTTP/3, it works through NATs and firewalls with the same ease as HTTP does. "RealTime Internet Peering for Telephony (RIPT) Compatibility with webRTC", Jonathan Rosenberg, 2020-02-07, The Real-Time Internet Peering for Telephony (RIPT) Protocol defines a technique for establishing, terminating and otherwise managing calls between entities in differing administrative domains. The RIPT Inbound extension brings this to end clients, such as a browser. However, it defines a different technique for media that cannot directly use the webRTC APIs, and require a change to them. This specification provides an extension to RIPT for webRTC compatibility, enabling media to flow from browser to server as is done with RIPT, or from browser to browser as is done with webRTC. It also discusses techniques for sending e2e encrypted media. "Real Time Internet Peering for Telephony (RIPT) Comparison with the Session Initiaton Protocol (SIP)", Jonathan Rosenberg, 2020-02-07, The Real-Time Internet Peering for Telephony (RIPT) protocol and its extension for inbound calls to single user devices provide an alternative to the Session Initiation Protocol (SIP) for several use cases. This leads to many questions - how is RIPT different from SIP and why? What should be standardized and what should not? How much of SIP do those two specifications replace? This document discusses the differences and their motivations, and presents an analysis across the set of SIP specifications, and analyzes whether the two RIPT documents replace each with similar capability, whether they eliminate the need for that specification, or whether some or all of that specification are not addressed by RIPT. "RealTime Internet Peering for Single User Endpoints", Jonathan Rosenberg, 2020-02-07, The Real-Time Internet Peering for Telephony (RIPT) protocol defines a technique for establishing, terminating and otherwise managing calls between entities in differing administrative domains. While it can be used for single user devices like an IP phone, it requires the IP phone to have TLS certificates and be publically reachable with a DNS record. This specification remedies this by extending RIPP to enable clients to receive inbound calls. It also provides basic single-user features such as forking, call push and pull, third-party call controls, and call appearances. It describes techniques for resiliency of calls, especially for mobile clients with spotty network connectivity. "A Web Model where Content Is Stored in a File's Source: The Unentangled Network", Michele Fabbrini, 2020-02-08, This document describes an experimental model of web whose main characteristic is that the content is stored in a file's source and accessed through a common text browser from the command line under Linux Os. This work also aims to evaluate the implications of such a network in relation, among other aspects, to security and tracking. "PRECIS Framework and Unicode 12.0.0", Takahiro Nemoto, 2020-02-09, This document describes the changes between Unicode 6.3.0 and Unicode 12.0.0 in the context of PRECIS in the same way as draft-faltstrom- unicode12-00. This document provides the information needed to consider whether the PRECIS framework can follow the updates of the Unicode standard since Unicode 6.3.0. "Virtual Transport Network (VTN) Scalability Considerations for Enhanced VPN", Jie Dong, Zhenbin Li, Fengwei Qin, 2020-02-10, Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. An enhanced VPN could be used for transport network slicing in 5G, and will also be of use in more generic scenarios. I-D.ietf-teas-enhanced-vpn describes the framework and candidate component technologies for providing enhanced VPN services. 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 (VTN) Identifier in IPv6 Extensison Header for Enhanced VPN", Jie Dong, Zhenbin Li, 2020-02-10, This document proposes a new option type to carry virtual transport network identifier (VTN ID) in the IPv6 extensions headers to identify the virtual transport network the packet belongs to. The procedure of processing the VTN option is also specified. This provides a scalable solution for data plane encapsulation of enhanced VPN (VPN+) as described in I-D.ietf-teas-enhanced-vpn. One typical use case of VPN+ is to provide transport network slicing in 5G, while it could also be used in more general cases. "Generalized SRv6 Network Programming", Weiqiang Cheng, Zhenbin Li, Cheng Li, Chongfeng Xie, Li Cong, Hui Tian, Feng Zhao, 2020-03-09, 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-02-11, 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. "JSContact: Converting from and to vCard", Mario Loffredo, Robert Stepanek, 2020-03-28, This document provides an informational guidance for converting the contact card defined by JSContact specification, namely JSCard, from and to vCard. "5G End-to-end Network Slice Mapping from the view of Transport Network", Xuesong Geng, Jie Dong, Ran Pang, Liuyan Han, Tomonobu Niwa, Jaewhan Jin, Chang Liu, Nikesh Nageshar, 2020-04-23, Network Slicing is one of the core featrures in 5G. End-to-end network slice consists of 3 major types of network segments: Access Network (AN), Mobile Core Network (CN) and Transport Network (TN). This draft describes the procedure of mapping relationship between 5G end-to-end network slice and transport network slice defined in IETF. This draft also intends to expose some gaps in the existing network management plane and data plane to support inter-domain network slice mapping. Further work may require cooperation between IETF and 3GPP (or other standard organizations). The definition of data model, signaling protocol extension and new encapsulation are out of the scope of this draft. "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Yaron Sheffer, Ralph Holz, Peter Saint-Andre, 2020-02-17, Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. "BGP Extension for SR-MPLS Entropy Label Position", Jin Zhou, Shaofu Peng, 2020-02-17, This document proposed an extension for BGP to configure the entropy label position for SR-MPLS networks. "JSON Responses for the Registration Data Access Protocol (RDAP)", Scott Hollenbeck, Andrew Newton, 2020-05-08, This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. "Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces", Fred Templin, Tony Whyman, 2020-05-20, 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 IPv6 packets over Overlay Multilink Network (OMNI) Interfaces. "Controlled Delay Approximate Fairness AQM", Jonathan Morton, Peter Heist, 2020-03-09, This note presents CodelAF, or Controlled Delay Approximate Fairness in full, as an alternative to single-queue AQM or Fair Queue implementations in the low-cost or high-speed network hardware spaces. It builds on the seminal work in Codel [RFC8289], and guides multiple competing flows towards similar throughputs by differential congestion signalling, whilst requiring only a single FIFO queue. It may also be combined with CNQ [I-D.morton-tsvwg-cheap-nasty-queueing] to provide a latency optimisation for sparse flows. "SDP Mapping into HTTP structured headers", James Gruessing, 2020-02-19, 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. "Shorter SRv6 SID Requirements", Weiqiang Cheng, Ran Chen, Liu Aihua, Greg Mirsky, 2020-02-19, This document describes a list of requirement for Shorter SRv6 SID. "JMAP for Sieve Scripts", Ken Murchison, 2020-03-05, This document specifies a data model for managing Sieve scripts on a server using JMAP. Open Issues o How should doing /set{create} with an existing script name be handled? Should it fail or overwrite the existing script? Should the /set request include an 'overwrite' boolean argument? o Should setting isActive==true on a script automatically deactivate any other existing active script, or should the client have to do so itself (as is currently documented)? o Do we want/need a SieveScript/copy method? o Do we want to leverage draft-ietf-jmap-quotas to query Sieve script storage quotas? "Shorter SRv6 SID Requirements", Weiqiang Cheng, Chongfeng Xie, Ran Pang, Zhenbin Li, Ran Chen, Lijun, Xiaodong Duan, Greg Mirsky, 2020-03-09, This document describes a list of requirements for the use of a shortened identifier in a segment routing network with the IPv6 data plane. "Multiformats", James Snell, Nicola Greco, Juan Benet, David Dalrymple, David Dias, Lars Gierth, 2020-02-24, Defines Multiformats, a collection of data formats that aim to future-proof systems by adding self-description to format values; and defines the Multihash and Multibase Multiformat data formats. "Additional Multiformat Codec Registrations", James Snell, Nicola Greco, Juan Benet, David Dalrymple, David Dias, Lars Gierth, 2020-02-24, This document defines additional registrations for the Multiformats Codec Registry. "UUID Format Update", Brad Peabody, 2020-02-24, This document presents a new UUID format (version 6) which is suited for use as a database key. A common case for modern applications is to create a unique identifier to be used as a primary key in a database table that is ordered by creation time, difficult to guess and has a compact text format. None of the existing UUID versions fulfill each of these requirements. This document is a proposal to update RFC4122 with a new UUID version that addresses these concerns. "Quic Timestamps For Measuring One-Way Delays", Christian Huitema, 2020-03-01, 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. "NET-PGM extension: SRv6 uSID illustration", Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Daniel Voyer, Israel Meilik, Keyur Patel, Wim Henderickx, Prem Jonnalagadda, David Melman, 2020-02-25, This document illustrates the SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction. "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Randy Bush, Rob Austein, 2020-02-26, In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. "Trusted Path Routing using Remote Attestation", Eric Voit, 2020-03-09, There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. This specification describes two alternatives for protecting these sensitive flows as they transit a network. In both alternatives, protection is accomplished by forwarding sensitive flows across network devices currently appraised as trustworthy. "Bidirectional Forwarding Detection (BFD) Padding Alteration", Xiao Min, 2020-02-28, This document describes the procedures of the Bidirectional Forwarding Detection (BFD) protocol to alter BFD padding, using BFD in Asynchronous mode. "BGP Flow Specification Extensions to Enable In-situ Flow Information Telemetry (IFIT)", Liu Min, Yali Wang, Ran Pang, 2020-03-23, BGP Flowspec mechanism propogates both traffic Flow Specifications and Traffic Filtering Actions by making use of the Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) and the BGP Extended Community encoding formats. In order to address the automatic deployment of IPv4 unicast and VPNv4 unicast on-path flow telemetry as well as IPv6 families, this document specifies a new BGP Extended Community named IFIT Action Specific Extended Community to distribute In-situ Flow Information Telemetry (IFIT) actions. "NTS for the NTP pool", Watson Ladd, 2020-02-28, Network Time Security authenticates NTP servers. This document outlines an architecture that uses ACME and SRV records for the NTP pool to carry out NTS. "Metadata in SR Service Programming Considerations", Liu Yao, 2020-03-01, This document discusses different ways to carry metadata in SR service programming data plane. "Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", Yuhei Hayashi, chenmeiling, 2020-03-02, 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. "Local Protection Enforcement in PCEP", Andrew Stone, Mustapha Aissaoui, Siva Sivabalan, 2020-03-02, This document aims to clarify existing 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. "Adaptive Subscription to YANG Notification", Zitao Wang, Qin WU, Wei Song, Liang Geng, Peng Liu, 2020-03-03, This document defines a YANG data model and associated mechanism enabling subscriber's adaptive subscriptions to a publisher's event streams. Applying these elements allows a subscriber to automatically adjust the volume of telemetry traffic sent from publisher to the receivers. "Telemetry Data Export capability", Ran Tao, Qin WU, Liang Geng, 2020-03-03, This document proposes a YANG module for telemetry data export capability which augments system Capabilities model and provide additional telemetry data export attributes associated with system capability for transport dependent capability negotiation. "Approaches on Supporting IOAM in IPv6", Haoyu Song, Zhenbin Li, Shuping Peng, 2020-03-03, 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 its location in the IPv6 header packets, this arrangement creates practical challenges for implementation, especially when other extension headers, such as 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 foster standard convergence and industry adoption. "An Algorithm for Computing Dynamic Flooding Topologies", Yunxia Chen, Tony Li, 2020-03-03, Link-state routing protocols suffer from excessive flooding in dense network topologies. Dynamic flooding [I-D.ietf-lsr-dynamic-flooding] alleviates the problem by decoupling the flooding topology from the physical topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the physical topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used as a flooding topology in dynamic flooding. This document discloses the algorithm that we have developed in order to make it easier for other developers to implement similar algorithms. We do not claim that our algorithm is optimal, rather it is a pragmatic effort and we expect that further research and refinement can improve the results. We are not proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work, however we have no objections if the working group chooses to do so. "Impact of TLS 1.3 to Operational Network Security Practices", Nancy Cam-Winget, Eric Wang, Roman Danyliw, Roelof DuToit, 2020-03-03, 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. "Encrypted DNS Discovery and Deployment Considerations for Home Networks", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook, 2020-05-15, This document discusses DoT/DoH deployment considerations for home networks. It particularly sketches the required steps to use DoT/DoH capabilities provided by local networks. The document specifies new DHCP and Router Advertisement Options to convey a DNS Authentication Domain Name. "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Christian Amsuess, 2020-03-04, 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. "Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint Trees", Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Daniel Voyer, Zhaohui Zhang, 2020-03-04, 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. "Methodology for Researching Security Considerations Sections", Mark McFadden, Alan Mills, 2020-03-04, 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 RFC3553, an examination of recent, published Security Considerations sections be carried out as a baseline for how to improve RFC3553. 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. "Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng, Daniel Voyer, Cong Li, Liang Geng, Chang Cao, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2020-03-05, 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-03-05, 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 and Liveness Monitoring in Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Navin Vaghamshi, Moses Nagarajah, 2020-03-05, 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 and Liveness Monitoring (PLM) in Segment Routing networks. The procedure uses the probe messages defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP) Light) as well as STAMP and is applicable to both SR-MPLS and SRv6 data planes. "Multiplexing Scheme Updates for QUIC", Bernard Aboba, Gonzalo Salgueiro, Colin Perkins, 2020-03-05, This document defines how QUIC, Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. This document updates RFC 7983 and RFC 5764. "Signed Public Key and Challenge", Graham Leggett, Dirk-Willem van Gulik, 2020-03-05, This memo describes the Signed Public Key and Challenge (SPKAC), a syntax to provide Proof-of-Possession of a Public Key to support federated (client) certificate enrolment. "Key Components for Multipath QUIC Traffic Distribution", Qing An, Dapeng Liu, Yanmei Liu, 2020-03-05, This document describes several key components for Multipath QUIC traffic distribution. The key components remain compliant with the current Multipath Extensions for QUIC (MP-QUIC) design. "Announcing Supported Authentication Methods in IKEv2", Valery Smyslov, 2020-03-11, This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple different credentials to authenticate each other. "Active-Scanning profiles for IoT devices", Jie Yang, Liang Xia, 2020-03-06, This draft extends MUD [RFC8520] model for the active scanning during the end host device on-boarding. The according features include TCP/ UDP port scanning, weak password detection, mandatory and hazardous services detection, etc, which can help administrator to discover system security vulnerabilities in advance. "Advancing ACK Handling for Wireless Transports", Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang, 2020-03-06, Acknowledgement (ACK) is a basic function and implemented in most of the ordered and reliable transport protocols [RFC0793]. Legacy TCP ACK is designed with high frequency to guarantee correct interaction between sender and receiver. However, the shared nature of the wireless medium over wireless local area network (WLAN) induces contention between data transport and backward signaling, such as acknowledgement. The current way of TCP acknowledgment induces control overhead which is counter-productive for TCP performance especially for WLAN scenarios. This document conducts the ACK frequency breakdown, analyzes several ways of reducing ACK frequency, and discusses the compatibility issues with existing systems in detail. "Indicators of Compromise (IoCs) and Their Role in Attack Defence", Kirsty P, Ollie Whitehouse, 2020-03-06, 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 endpoint security appliances or network-based defences, or ideally both) to be effective. "SRv6 network programming using Unified Identifier", Weiqiang Cheng, Greg Mirsky, Liu Aihua, Shaofu Peng, 2020-03-06, This draft describes how Unified Segment Identifier can be used to achieve the goals of SRv6 network programming. "Conveying Transceiver-Related Information within RSVP-TE Signaling", Julien Meuric, Esther Le Rouzic, Luay Alahdab, Gabriele Galimberti, 2020-03-06, 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-03-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-03-16, This document provides guidance regarding the processing, insertion and deletion of IPv6 extension headers. It updates RFC 8200. "Bootstrapped TLS Authentication", Owen Friel, Dan Harkins, 2020-03-06, This document defines a TLS extension that enables a server to prove to a client that it has knowledge of the public key of a key pair where the client has knowledge of the private key of the key pair. Unlike standard TLS key exchanges, the public key is never exchanged in TLS protocol messages. Proof of knowledge of the public key is used by the client to bootstrap trust in the server. The use case outlined in this document is to establish trust in an EAP server. "Sender Control of Delayed Acknowledgments in TCP: Problem Statement, Requirements and Analysis of Potential Solutions", Carles Gomez, Jon Crowcroft, 2020-03-26, TCP Delayed Acknowledgments (ACKs) allow reducing protocol overhead in many scenarios. However, in some cases, Delayed ACKs may significantly degrade network and device performance in terms of link utilization, latency, memory usage and/or energy consumption. This document presents the problem statement regarding sender control of Delayed ACKs in TCP. The document discusses the scenarios and use cases in which sender control of Delayed ACKs offers advantages. Then, requirements for a potential solution are derived. Finally, a number of potential solutions are discussed, based on the requirements, and also considering pros and cons in each case. "BGP Extensions for Unified SID in TE Policy", Liu Yao, Shaofu Peng, 2020-05-11, This document defines extensions to BGP in order to advertise Unified SIDs in SR-TE policies. "The OAuth 2.1 Authorization Framework", Dick Hardt, Aaron Parecki, Torsten Lodderstedt, 2020-04-24, 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. "A User-Focused Internet Threat Model", Dominique Lazanski, 2020-03-08, RFC 3552 introduces a threat model that does not include endpoint security. RFC 3552 is 15 years old and in those 15 years the 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 RC 3552. "No Further Fast Reroute", Kireeti Kompella, Wen Lin, 2020-03-08, There are several cases where, once Fast Reroute has taken place (for MPLS protection), a second fast reroute is undesirable, even detrimental. This memo gives several examples of this, and proposes a mechanism to prevent further fast reroutes. "BGP for Network High Availability", Huaimo Chen, Yanhe Fan, Aijun Wang, Lei Liu, Xufeng Liu, 2020-03-08, This document describes protocol extensions to BGP for improving the reliability or availability of a network controlled by a controller cluster. "PCEP Extension for SRv6 Unified SIDs", Quan Xiong, Shaofu Peng, 2020-05-11, This document proposes PCEP extensions for SRv6 Path which applied to the use of SRv6 Unified SIDs. "PCE for Network High Availability", Huaimo Chen, Aijun Wang, Lei Liu, Xufeng Liu, 2020-03-08, This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for improving the reliability or availability of a network controlled by a controller cluster. "UDP based Publication Channel for Streaming Telemetry", Guangying Zheng, Tianran Zhou, Alexander Clemm, Thomas Graf, Pierre Francois, Paolo Lucente, 2020-03-30, This document describes a UDP-based publication channel for streaming telemetry use to collect data from devices. A new shim header is proposed to facilitate the distributed data collection mechanism which directly pushes data from line cards to the collector. Because of the lightweight UDP encapsulation, higher frequency and better transit performance can be achieved. "Subscription to Multiple Stream Originators", Tianran Zhou, Guangying Zheng, Eric Voit, Alexander Clemm, Thomas Graf, Pierre Francois, 2020-03-08, This document describes the distributed data export mechanism that allows multiple data streams to be managed by using a single subscription. Specifically, device can decide to decompse one subscription into multiple subscriptions to the line-cards. So that each line-card can directly push data to the collector without passing through a broker for internal consolidation. And the device can indicate the subscription decomposition result to the receiver to check the data integrity. "YANG Data Model for Sync PHY", Yuanlong Jiang, Jingfei Lv, Liuyan Han, 2020-03-08, This document defines a YANG data model for the configuration of physical layer synchronization including SyncE and SyncO. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). "Conditional HTTP Requests Using Digests", Martin Thomson, 2020-03-08, Header fields are defined for making HTTP requests that are conditional on the content of the selected representation of a resource. "IGP for Network High Availability", Huaimo Chen, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu, 2020-03-08, This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. "Egress Protection for Segment Routing (SR) networks", Shraddha Hegde, Wen Lin, 2020-03-08, 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 [I-D.ietf-mpls-egress-protection-framework]. 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. "Simple Registration Reporting", Joseph Yee, James Galvin, 2020-04-10, Domain name registries and registrars report to each other by sharing bulk information through files. This document creates two IANA registries to create a standard reporting mechanism between domain name registries and registrars. The first IANA registry lists standard data elements and their syntax for inclusion in the files. The second IANA registry lists standard reports based on the standard data elements. Each report is a file formatted as a CSV file. The advantage of this reporting mechanism is that reports, each file, can be imported by recipients without any prior knowledge of their contents, although reporting is enhanced with a minimum of knowledge about the files. The mechanism for the transmission and reception of the files is a matter of local policy. "A Yang Data Model for Transport Slice", Wu Bo, Dhruv Dhody, Liuyan Han, Reza Rokui, 2020-04-17, This document provides a YANG data model for the transport slice service. The model can be used by a client management system of the transport slice controller to request, configure, and manage the components of an transport slice service. The YANG modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Use cases of Application-aware Networking (APN) in Edge Computing", Peng Liu, Liang Geng, Shuping Peng, Zhenbin Li, 2020-03-09, 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-03-09, This document presents two demand scenarios from the Internet Service Providers' perspective as an supplement use case of the RATS work group. And make some discussions from the two dimensions of access authentication and application authentication. "Content-Based Origins for the Web", Martin Thomson, 2020-03-09, Making content available to clients that are unable or unwilling to contact a web origin enables new means of acquiring content. This document describes a method for taking application state accumulated by an offline user agent in relation to a piece of content and making that state available in a fully online context. This enables continuous use of content, starting from a state where the user agent does not contact an origin and ending with This document proposes an update to the definition of Origin in RFC 6454. It also proposes changes that would affect HTML, which is outside of the remit of the IETF. "An Architecture for Network Function Interconnect", Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, 2020-03-09, The emergence of technologies such as 5G, the Internet of Things (IoT), and Industry 4.0, coupled with the move towards network functionvirtualization, 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. "Privacy Pass: The Protocol", Alex Davidson, 2020-03-09, This document specifies the Privacy Pass protocol for privacy- preserving authorization of clients to servers. The privacy requirement is that client re-authorization events cannot be linked to any previous initial authorization. Privacy Pass is intended to be used as a performant protocol in the Internet setting. "Redundancy Policy for Redundant Protection", Xuesong Geng, Mach Chen, 2020-03-23, Redundancy protection is a method of service protection by sending copies of the same packets of one flow over multiple paths, which includes packet replicaiton, elimination and ordering. This document defines redundancy policy as an extension to the current SR policy to support redundancy protection. "Privacy Pass: Architectural Framework", Alex Davidson, 2020-03-09, This document specifies the architectural framework for constructing secure and privacy-preserving instantiations of the Privacy Pass protocol (as described in [draft-davidson-pp-protocol]). The framework refers to the entire ecosystem of Privacy Pass clients and servers. This document makes recommendations on how this ecosystem should be constructed to ensure the privacy of clients and the security of all participating entities. "Redundancy SID and Merging SID for Redundancy Protection", Xuesong Geng, Mach Chen, 2020-03-09, Redundancy protection is a method of service protection by sending copies of the same packets of one flow over multiple paths, which includes packet replication, elimination and ordering. This document defines Redundancy SID and Merging SID to support redundancy protection. "SRH Extension for Redundancy Protection", Xuesong Geng, Mach Chen, 2020-03-09, Redundancy protection is a method of service protection by sending copies of the same packets of one flow over multiple paths, which includes packet replicaiton, elimination and ordering. This document defines SRv6 header(SRH) extensions to support redundancy protection. "Privacy Pass: HTTP API", Steven Valdez, 2020-03-09, This document specifies an integration for Privacy Pass over an HTTP API, along with recommendations on how key commitments are stored and accessed by HTTP-based consumers. "Client-Server Explicit Performance Measurements", Mauro Cociglio, Giuseppe Fioccola, Massimo Nilo, Fabio Bulgarella, Riccardo Sisto, 2020-03-23, This document introduces an additional single bit signal to enhance the spin bit [I-D.trammell-ippm-spin] performance in presence of network impairments and application limited flow. In addition, it defines two new explicit per-flow transport-layer signals for hybrid measurement of connection loss rate. The former is a spin-bit dependent signal and uses a single bit. The latter is a standalone solution based on a two bits loss signal and on alternate marking RFC 8321 [RFC8321]. "Distributed SFC control operation", Carlos Bernardos, Alain Mourad, 2020-03-09, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document describes a general framework for distributed SFC operation. "NSH extensions for local distributed SFC control", Carlos Bernardos, Alain Mourad, 2020-03-09, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies several NSH extensions to provide in-band SFC control signaling. "SFC function mobility with Mobile IPv6", Carlos Bernardos, Alain Mourad, 2020-03-09, Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies Mobile IPv6 extensions to enable function migration in SFC. "Algorithm Related IGP-Adjacency SID Advertisement", Shaofu Peng, Ran Chen, 2020-03-09, Segment Routing architecture supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document will 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-03-09, 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 draft- ietf-ippm-multipoint-alt-mark, it explains how to implement performance measurement analytics on the Network Management System by analysing the raw data of the network nodes. "RSVP-TE Extensions in Support of Proactive Protection", Yi Lin, Bin-Yeong Yoon, 2020-03-09, This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support Label Switched Path (LSP) Proactive Protection, which create the protecting LSP after a failure is predicted and before it becomes a real failure. "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network", Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li, 2020-03-09, Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to support some applications's needs of enhanced isolation and stringent performance requirements. VPN+ requries 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 toplogy 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 IGP 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-03-09, 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+ requries 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 toplogy 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 with minor extensions to IGP L2 bundle. "Using MUD on CoAP environments", Jaime Jimenez, 2020-03-09, This document provides some guidelines on how to add Manufacturer Usage Descriptions (MUD) to CoAP environments. "SVG Fun with kramdown-rfc2629", Thomas Fossati, 2020-03-13, This memo is for experimenting with SVG in the context of RFC production. "Retry-Scope header field", Roberto Polli, 2020-03-09, This document defines the Retry-Scope header field for HTTP thus allowing a server to communicate the scope of the returned Retry- After header field. "Tunneling TCP inside QUIC", Maxime Piraux, Olivier Bonaventure, 2020-03-09, This document specifies a new operating mode for a QUIC tunnel to efficiently convey TCP bytestreams. "Unaffiliated BFD Echo Function", Weiqiang Cheng, Ruixue Wang, Xiao Min, Liu Aihua, 2020-03-09, Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can quickly determine a communication failure between devices and notify upper-layer applications [RFC5880]. BFD has asynchronous detecting mode and demand detection mode to satisfy different scenarios, also supports echo function as an adjunct to both modes to reduce the device requirement for BFD. Unaffiliated BFD echo function described in this document reuses the BFD echo function as described in [RFC5880] and [RFC5881], but independent of BFD asynchronous mode or BFD demand mode, that means it doesn't need BFD protocol capability of state machine, but only BFD echo function to a deployed device supporting BFD detection. When using unaffiliated BFD echo function, just the local device works on BFD protocol and the BFD peer doesn't, which only loopback the received BFD echo packets as usual data packets without enabling BFD protocol. Section 6.2.2 of [BBF-TR-146] describes one use case of the unaffiliated BFD echo function, and at least one more use case is known in the field BFD deployment. "QUIC Plugins", Maxime Piraux, Quentin Coninck, Francois Michel, Florentin Rochet, Olivier Bonaventure, 2020-03-09, The extensibility of Internet protocols is a key factor to their success. Yet, their implementations are often not designed with agility in mind. In this document, we leverage the features of the QUIC protocol and propose a solution to dynamically extend QUIC implementations. Our solution relies on QUIC Plugins that allow tuning and extending the QUIC protocol on a per-connection basis. These platform-independent plugins are executed inside a sandboxed environment which can be included in QUIC implementations. We describe how such plugins can be used in different use cases. This document is a straw-man proposal. It aims at sparking discussions on the proposed approach. "The SRT Protocol", Maxim Sharabayko, Maria Sharabayko, Jean Dube, Joonwoong Kim, Jeongseok Kim, 2020-03-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. Note to Readers Source for this draft and an issue tracker can be found at https://github.com/haivision/srt-rfc (https://github.com/haivision/ srt-rfc). "DNS Resolver Discovery Protocol (DRDP)", Daniel Migault, 2020-03-24, 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 resolver may also inform the DNS client other resolving services are available and eventually preferred. "Problem Statement of Signal Degrade Indication for Segment Routing over MPLS Network", Fan Yang, Liuyan Han, Junfeng Zhao, 2020-03-09, 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 the networks of Segment Routing (SR) over MPLS. "BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks", Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li, 2020-03-09, Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to support applications's needs of enhanced isolation and stringent performance requirements. VPN+ requries 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 toplogy 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-idr-bgpls-sr-enhanced-vpn defines the BGP-LS extensions to distribute the information of Segment Routing (SR) based VTNs to external entities, such as the network controllers. This document describes a simplified mechanism to distribute the information of SR based VTNs using BGP-LS with Multi-Topology. "BGP-LS with Flex-Algo for Segment Routing based Virtual Transport Networks", Yongqing Zhu, Jie Dong, Zhibo Hu, 2020-03-09, Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to support applications's needs of enhanced isolation and stringent performance requirements. VPN+ requries 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 toplogy 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-idr-bgpls-sr-enhanced-vpn defines the BGP-LS extensions to distribute the information of Segment Routing (SR) based VTNs to external entities, such as the network controllers. This document describes a simplified mechanism to distribute the information of SR based VTNs using BGP-LS with Flex-Algo. "Use cases for DIS Modifications", Georgios Papadopoulos, 2020-03-09, This document presents some of the use-cases which call for DIS flags and options modifications. "Security Considerations for Protocol Designers", Dominique Lazanski, 2020-03-09, This document is a non-exhaustive set of considerations for protocol designers and implementers with regards to attack defence. These considerations 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 in its this section. Defence against malicious attacks can be improved and it can be weakened by design features of protocols. Designers should acknowledge the role of protocols in attack prevention, detection and mitigation; this document aims to be a useful guide in doing so. "Auto-adjustment of Encapsulation Information in APN6", Zongpeng Du, Peng Liu, Liang Geng, 2020-03-09, This document introduces a method to adjust the encapsulation information in Application-aware IPv6 Networking. "Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic", Zongpeng Du, Peng Liu, Liang Geng, 2020-03-09, This document introduces a method to decrease the micro-bursts in Layer3 network for low-latency traffic. "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Randy Bush, Rob Austein, 2020-03-09, In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. "Embedding LOOPS in SRv6", Jianglong, Shizhong Nie, Lei Bo, Carsten Bormann, 2020-03-09, LOOPS (Local Optimizations on Path Segments) aims to provide local in-network loss recovery. It can be used with tunneling protocols to efficiently recover lost packets on a single segment of an end-to-end path instead of leaving recovery to the end-to-end protocol, traversing the entire path. Segment Routing (SR) leverages the source routing mechanisms and steers the packets through an policy instantiated as an ordered list of instructions called segments. LOOPS can be embedded in an SR segment to improve the packet recovery. draft-welzl-loops-gen-info defines the generic information model, without binding that to any specific protocols, to be carried between LOOPS ingress and egress nodes, which can be SR segment endpoints. This document specifies the concrete mechanisms to embed LOOPS in SRv6 segment. "BCP72 - A Problem Statement", Mark McFadden, 2020-03-09, RFC3552/BCP72 describes an Internet Threat model that has been used in Internet protocol design. More than sixteen years have passed since RFC3552 was written and the structure and topology of the Internet has changed. With those changes comes a question: has the Internet Threat Model really changed? Or, is the model described in RFC3552 still largely accurate? This draft attempts to describe an non-exhaustive list of changes in the current threat environment. It suggests 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. "5G - Ultra-Reliable Wireless Technology with Low Latency", Janos Farkas, Torsten Dudda, Alexey Shapin, Sara Sandberg, 2020-03-09, This document describes the features of 5G that make it a wireless technology providing ultra-reliability, high availability, and low latency; and looks out to possibilities on the application of 5G together with IETF Deterministic Networking (DetNet). "Use Cases and Requirements for QUIC as a Substrate", Mirja Kuehlewind, Zaheduzzaman Sarker, Thomas Fossati, Lucas Pardue, 2020-03-09, In situations where direct connectivity is not available or desired, proxies in the network are used to forward and potentially translate traffic. TCP is often used as a proxying or tunneling protocol. QUIC is a new, emerging transport protocol and there is a similar expectation that it too will be used as a substrate once it is widely deployed. Using QUIC instead of TCP in existing scenarios will allow proxying and tunneling services to maintain the benefits of QUIC natively, without degrading the performance and security characteristics. QUIC also opens up new opportunities for these services to have lower latency and better multistreaming support. This document summarizes current and future usage scenarios to derive requirements for QUIC as a substrate and to provide additional considerations for proxy signaling and control protocol as proposed by MASQUE. "Parameterized Nameserver Delegation with NS2 and NS2T", Tim April, 2020-03-09, Within the DNS, there is no mechanism for authoritative servers to advertise which transport methods they are capable of. If secure transport methods are adopted by authoritative operators, protocol negotiation would be required. This document provides two new Resource Record Types, NS2 and NS2T, to facilitate that negotiation by allowing zone owners to signal how the authoritative nameserver(s) for their zone(s) may accept queries. "Forwarding Layer Problem Statement", Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm, 2020-03-09, This document considers the new use cases for IP together with the network capabilities and services that will be needed to address those use cases. It then looks at the underlying packet requirements and considers the changing deployment models and the issues with existing packet designs that need to be addressed. It concludes by looking at some parameters of a solution. "MoWIE for Network Aware Application", Wei Huang, Yunfei Zhang, Richard Yang, Chunshan Xiong, Yixue Lei, Yunbo Han, Gang Li, 2020-03-09, 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. "Connection-oriented Path in SRv6 Network", Zongpeng Du, Peng Liu, Liang Geng, 2020-03-09, This document proposes a method to support connection-oriented path in the SRv6 network. "SPAKE2+, an Augmented PAKE", Tim Taubert, Christopher Wood, 2020-03-09, 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-03-09, 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, 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 encounter current shortcomings of cyber-security and data privacy. "Signaling resolver's filtering policies", Daniel Migault, 2020-03-09, This document defines one mechanism that enables a DNS resolver to inform a DNS client that filtering policies are in place and what their concern is. The second mechanism describes how a DNS client can request a resolver whether filtering policies are in place and what their concern is. "Guidance for External PSK Usage in TLS", Russ Housley, Jonathan Hoyland, Mohit Sethi, Christopher Wood, 2020-04-06, This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. "Framework for Transport Network Slices", Eric Gray, John Drake, 2020-04-22, This memo discusses setting up special-purpose transport connections using existing IETF technologies. These connections are called transport slices for the purposes of this memo. The memo discusses the general framework for this setup, the necessary system components and interfaces, and how abstract requests can be mapped to more specific technologies. The memo also discusses related considerations with monitoring and security. This memo is intended for discussing interfaces and technologies. It is not intended to be a new set of concrete interfaces or technologies. Rather, it should be seen as an explanation of how some existing, concrete IETF VPN and traffic-engineering technologies can be used to create transport slices. Note that there are is a rather large of these technologies, and new technologies or capabilities keep being added. This memo is also not intended presume any particular technology choice. "Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk, 2020-03-09, 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 originator servers, by acquiring their addressing information. "EAP-TLS with PSK Authentication (EAP-TLS-PSK)", John Mattsson, Mohit Sethi, Tuomas Aura, Owen Friel, 2020-03-09, While TLS 1.3 supports authentication with Pre-Shared Key (PSK), EAP- TLS with TLS 1.3 explicitly forbids PSK authentication except when used for resumption. This document specifies a separate EAP method (EAP-TLS-PSK) for use cases that require authentication based on external PSKs. "A CBOR Tag for Unprotected CWT Claims Sets", Henk Birkholz, Nancy Cam-Winget, Carsten Bormann, 2020-03-09, 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. "Transport Slice Intent", Luis Contreras, Panagiotis Demestichas, 2020-03-09, Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introducion of new services such as 5G. This document explores the usage of intent machanisms for requesting transport slices. "CBOR Certificate Algorithm for TLS Certificate Compression", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2020-03-09, Certificate chains often take up the majority of the bytes transmitted in TLS handshakes. Large handshakes can cause problems, particularly in constrained IoT environments. RFC 7925 defines a TLS certificate profile for constrained IoT. General purpose compression algorithms can in many cases not compress RFC 7925 profiled certificates at all. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document specifies the CBOR certificate compression algorithm for use with TLS Certificate Compression in TLS 1.3 and DTLS 1.3. "CBOR Object Signing and Encryption (COSE): Headers for Carrying CBOR Compressed Certificates", John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2020-03-09, Certificate chains often take up the majority of the bytes transmitted in COSE message that carry certificates. Large messages can cause problems, particularly in constrained IoT environments. RFC 7925 defines a certificate profile for constrained IoT. General purpose compression algorithms can in many cases not compress RFC 7925 profiled certificates at all. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document specifies the CBOR certificate compression algorithm for use with COSE. "Non-Interactive Emergency Calls", Brian Rosen, 2020-03-09, Emergency calls from citizens to authorities, and call back of such emergency calls by authorities to citizens need assurances that headers intended to get appropriate priority from the networks they traverse, and in some cases, appropriate routing. Protection of the SIP Resource Priority Header and the SIP Priority header is needed for such calls. This document describes the environment for placing emergency calls and call backs which motivate the need and use of the mechanisms described in other documents "Mathematical Mesh 3.0 Part XIII: Mesh Ceremonies", Phillip Hallam-Baker, 2020-03-09, 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, Jessica Fitzgerald-McKay, David Waltermire, 2020-03-09, Concise Software Identification (CoSWID) tags identify and describe individual software components, patches, and installation bundles. CoSWID is based on ISO/IEC 19770-2:2015 2:2015 that provides a complementary XML schema definition (XSD) for Software Identification (SWID) tags. CoSWID supports the same features as the corresponding XML SWID tags. The CoSWID specification also includes more structured extensibility features and reduces a few of ambiguities that are not explicitly resolved in the ISO XSD. In this document, these extensibility features (extension points) are used to add attributes to the CoSWID specification. The new attributes allow for the use of CoSWID as Reference Integrity Measurements (RIM). There are three set of RIM features defined in this specification. 1.) attributes that support RIM manifests for Measured Boot, 2.) attributes that support package manager managed structures, and 3.) attributes that allow for OID to be used in the description of Reference Integrity Measurements. "BGP Well Known Large Community", Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley, 2020-03-09, A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities. "Key encoding for manual typing operations.", Bjoern Haase, 2020-03-09, This document specifies a string encoding of external pre-shared keys (PSK) for applications where the key has to be entered manually by use of an alphanumeric or numeric keyboard. "A Data Model for configuring Domain Name System (DNS) Zone Provisioning on Authoritative Nameservers", Pieter Lexis, Ladislav Lhotka, Petr Spacek, Ondrej Sury, Willem Toorop, 2020-04-13, This document describes a data model for configuring DNS Zone provisioning on authoritative nameservers. This data model only includes definitions for configuration of primary and secondary relationships. The purpose of this document is to enumerate the properties involved in managing zone provisioning, for usage in managing zone provisioning methods, such as catalog zones or NETCONF. "Multipath schedulers", Olivier Bonaventure, Maxime Piraux, Quentin Coninck, Matthieu Baerts, Christoph Paasch, Markus Amend, 2020-03-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-03-09, 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. "OAuth 2.0 DPoP for the Implicit Flow", Michael Jones, Brian Campbell, John Bradley, 2020-03-09, This specification 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 tokens. This specification compliments and builds upon the mechanisms defined in draft-fett-oauth-dpop, in which access tokens are returned from the token endpoint. In particular, this specification extends the Demonstration of Proof-of-Possession at the Application Layer (DPoP) mechanisms to also be usable with the OAuth 2.0 implicit flow, in which access tokens are returned from the authorization endpoint. "Hardening DNSSEC against collision weaknesses in SHA-1 and other cryptographic hash algorithms", Tony Finch, 2020-03-09, DNSSEC deployments have often used the SHA-1 cryptographic hash algorithm to provide authentication of DNS data. This document explains why SHA-1 is no longer secure for this purpose, and deprecates its use in DNSSEC signatures. This document updates RFC 8624. "Out-of-Band STIR for Service Providers", Jon Peterson, 2020-03-09, The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a SIP request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. "Considerations of Deploying ALTO using BGP - Link State (BGP-LS) Advertisement", Jingxuan Zhang, Kai Gao, Luis Contreras, Anais Escribano, Patricia Cano, Francisco Cano, 2020-03-09, This document discusses the requirements and deployment considerations of providing Application-Layer Traffic Optimization (ALTO) information in the inter-domain scenario using Border Gateway Protocol - Link State (BGP-LS) extension. "A CWT Claims Set Definition for RATS Endorsement Tokens", Henk Birkholz, Michael Eckel, 2020-03-09, An Endorsement is defined by the RATS Architecture as a "secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability". This documents defines Claims to be used in CBOR Web Tokens in the same fashion attestation Evidence can be represented via Entity Attestation Tokens (EAT). The defined Claims can be included in Endorsement Tokens. Endorsement Tokens can be provided by a manufacturer or a third party authority to vouch for the capabilities and characteristics of a hardware component a RATS Attester is not capable to create Evidence about. "WebTransport using HTTP/2", Alan Frindell, Eric Kinnear, Tommy Pauly, Victor Vasiliev, Guowu Xie, 2020-03-09, WebTransport is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes Http2Transport, a WebTransport protocol that is based on HTTP/2 and provides support for bidirectional streams multiplexed within the same HTTP/2 connection. "MUD-Based RATS Resources Discovery", Henk Birkholz, 2020-03-09, Manufacturer Usage Description (MUD) files and the MUD URI that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in an IEEE 802.1AR Secure Device Identifier (DevID). A DevID is a device specific pub- key identity document that can be presented to other entities, e.g. a network management system. If this entity is also a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references found in the MUD file specified in this document in order to discover appropriate Reference Integrity Measurements (RIM), Endorsement Documents, or even globally suitable Remote Attestation Services (RAS). All three types of theses resources are required to conduct RATS. Hence, the MUD file defined in this document enables remote attestation procedures by supporting the discovery of these required resources or services. "Supporting Multi-domain Use Cases with ALTO", Danny Perez, Christian Rothenberg, Qiao Xiang, Y. Yang, Borje Ohlman, Sabine Randriamasy, Farni Weaver, Luis Contreras, J. Zhang, Kai Gao, 2020-03-10, The goal of this document is to summarize current standardization efforts in the IETF ALTO working group to support important multi- domain use cases and show how they can benefit from network information exposure using ALTO. Besides, key design requirements of network information exposure to support multi-domain use cases are also presented along with information about novel mechanisms and abstractions to improve the base ALTO framework in multi-domain scenarios. "Multi-domain Service Function Chaining with ALTO", Danny Perez, Qiao Xiang, Christian Rothenberg, Y. Yang, 2020-03-10, The delivery of network services often require service functions and their specific order, called a service function chain (SFC). A SFC request is usually composed by distributed resources which are expected to available across multiple domains with different technology and/or administration. This document describes different standardization activities and research projects addressing the challenges posed by SFC across multiple domains (specifically, multiple administrative domains). In addition, this document presents an initial approach to realize inter-domain service chains leveraging the Application Layer Traffic Optimization (ALTO) protocol. Finally, another important concern of this document is to initiate a discussion (ALTO, SFC as well as other WGs) regarding if, how, and under what conditions ALTO can be useful to improve the multi-domain SFC process. "Abstract", Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li, 2020-03-11, 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-05-20, 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-03-12, 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 (mailto:masque@ietf.org) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts (https://github.com/DavidSchinazi/masque-drafts). "Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)", Thomas Graf, 2020-04-26, This document introduces additional code points in the mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3 MPLS Segment Routing (SR) extensions and a new SID type element to enable Segment Routing label and segment type information in IP Flow Information Export (IPFIX). "Additional Criteria for Nominating Committee Eligibility", Brian Carpenter, Stephen Farrell, 2020-03-28, 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 probable decline in face-to-face meetings. This document temporarily varies the rules in RFC 8713. "JSON Type Definition", Ulysse Carion, 2020-04-26, This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build. This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD. "Advisory Content-Length for HTTP", Mark Nottingham, 2020-03-17, The HTTP Content-Length header field is overloaded with (at least) two duties: message delimitation in HTTP/1, and metadata about the length of an incoming request body to the software handling it. This causes confusion, and sometimes problems. This document proposes a new header to untangle these semantics (at least partially). "BGP Extended Community Registries Update", Christoph Loibl, 2020-04-20, 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. "Domain Name System Uniform Resource Identifiers for DNS over HTTPS and DNS over TLS", Daniel Migault, 2020-03-18, Today DNS resources may also be accessed using multiple transport which includes DNS over UDP/TCP port 53 [RFC1034],[RFC1035]. DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484]. This document describes URIs that describes the DNS resource as well as indicate the transport to access the resource. "DNS Server Selection: DNS Server Information with Assertion Token", Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair, 2020-04-09, The document defines a mechanism that allows communication of DNS resolver information to DNS clients for use in 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 DNS-over-TLS and DNS-over-HTTPS servers that are either public resolvers or are discovered in a local network. "Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication", Alexey Melnikov, 2020-03-19, 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. "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", Murray Kucherawy, Elizabeth Zwicky, Tim Wicinski, 2020-04-06, Domain-based Message Authentication, Reporting, and Conformance (DMARC) 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. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document obsoletes RFC 7489. "Sieve: Internationalized Email", Stephan Bosch, 2020-03-21, This document defines an extension to the Sieve language called "eai" which adds full support for internationalized email. "In-situ Flow Information Telemetry (IFIT) Node Capability Advertisement", Yali Wang, Tianran Zhou, Liu Min, Ran Pang, 2020-03-22, For advertising In-situ Flow Information Telemetry (IFIT) node capabilities within the entire routing domain, this document extends a new optional TLV to the OSPF RI Opaque LSA, a new optional sub-TLV to the IS-IS Router CAPABILITY TLV, and a new Node Attribute TLV that is encoded in the BGP-LS attribute with Node NLRIs to carry IFIT node capabilities information. Such advertisement allows entities (e.g. a centralized controller) to determine whether a particular IFIT functionality can be supported in a given network. "CoRE Working Group -- Overview", Carsten Bormann, Jaime Jimenez, 2020-03-30, The IETF "Constrained RESTful Environments" (CoRE) Working Group standardizes application layer protocols that can be used by resource-constrained devices, as can be found in the Internet of Things (IoT). It is part of a cluster of about a dozen IETF WGs defining specifications for these environments. This short document provides an overview of the activities of the CoRE WG as of end of March, 2020. "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses", Mario Loffredo, Gavin Brown, 2020-04-20, 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-03-23, This document describes 7 Identity Claims for use in various Drone Remote ID Protocols (DRIP). "DRIP Authentication Formats", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2020-03-23, This document describes how to include trust into the ASTM Remote ID specification defined in ASTM3411 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. "Performance Measurement Using STAMP for Segment Routing Networks", Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens, 2020-03-23, 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 procedure for sending and processing probe query and response messages for Performance Measurement (PM) in Segment Routing networks. The procedure uses the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) for Delay Measurement, and uses the mechanisms defined in this document for Loss Measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes and is used for both Links and end-to-end SR Policies. "Command and Control Registry for SCHC", Pascal Thubert, 2020-03-25, This document creates a registry for command and control rule values across technologies "User Defined Resource Error HTTP Status Code", Colm Divilly, 2020-03-26, This document specifies an additional HyperText Transfer Protocol (HTTP) status code to indicate server error conditions arising during evaluation of a user defined resource hosted by the server, rather than in the server itself. Conventions and Terminology "Load-balancing and Stability Aware Objective Function (LBSA)", Baraq Ghaleb, Ahmed Al-Dubai, Imed Romdhani, Mamoun Qasem, 2020-03-27, The IPv6 Routing Protocol for Low-power and Lossy Networks (RPL) has been recently standardized as the de facto solution for routing in the context of the emerging Internet of Things (IoT) paradigm. RPL, along with other standards, has provided a baseline framework for IoT that has helped advance communications in the world of embedded resource-constrained networks. However, RPL still suffers from issues that may limit its efficiency such as the absence of an efficient load-balancing primitive. To address this problem, a novel load- balancing scheme is introduced that ensures a fair distribution of traffic among nodes while minimizing overhead "Variances to Provisions of Best Current Practices", Pete Resnick, 2020-03-27, From time to time, there are unforeseen circumstances which make following the requirements of a Best Current Practice (BCP) untenable, or where the procedures described in the BCP gives no guidance. This document defines a process for the IETF to grant a variance to any IETF process for a single use or of very short duration. "Real-time text solutions for multi-party sessions", Gunnar Hellstrom, 2020-03-28, This document specifies methods for Real-Time Text (RTT) media handling in multi-party calls. The main RTT transport is to carry Real-Time text by the RTP protocol in a time-sampled mode according to RFC 4103 [RFC4103] . 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. "Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect Authentication Scheme", Nico Williams, 2020-04-10, The Hyper-Text Transport Protocol (HTTP) offers several authentication schemes, but many sites use redirection-based protocols to authenticate users. Some servers are faced with a connundrum, having to choose between two mutually-exclusive options: redirect responses or 401 (authentication required) responses without knowing which the user-agent is most likely to support. This document specifies new HTTP request headers by which many applications can improve interoperability even without changing their HTTP implementations. These new headers allow user-agents to advertise authentication- and redirect-related capbilities that servers can use to better make authentication and/or redirect decisions. Also specified is a new HTTP authentication scheme named "Redirect" that enables communication between redirecting and redirected authorities via preservation of "Authorization" headers across redirections. This enables arbitrary authentication and authorization protocols to work without requiring user-agent support for them and without having to (ab)use URI query parameters. "IGP Extensions for Shorter SRv6 SID", Ran Chen, Shaofu Peng, 2020-05-11, This document describes the IGP extensions required to support the Shorter SRv6 SIDs( Compressing SRv6 SIDs). "Per-Node Capabilities for Optimum Operational Data Collection", Benoit Claise, Munish Nayyar, Adithya Sesani, 2020-03-30, 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 oeprations. "Applicability Statement for IETF Core Email Protocols", John Klensin, 2020-03-30, 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. "BGP-LS Extensions for Shorter SRv6 SID", Liu Yao, Shaofu Peng, 2020-03-30, 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-05-08, 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-05-25, 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. "5G - Ultra-Reliable Wireless Technology with Low Latency", Janos Farkas, Torsten Dudda, Alexey Shapin, Sara Sandberg, 2020-04-01, This document describes the features of 5G that make it a wireless technology providing ultra-reliability, high availability, and low latency; and looks out to possibilities on the application of 5G together with IETF Deterministic Networking (DetNet). "Eligibility for the 2020-2021 Nominating Committee", Barry Leiba, 2020-05-07, The 2020-2021 Nominating Committee (NomCom) is to be formed between IETF 107 and IETF 108, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one- time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108, and does not set a precedent for the future. "Reflexive Forwarding for CCNx and NDN Protocols", David Oran, Dirk Kutscher, 2020-04-17, Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. "YANG data model for shorter srv6", Ran Chen, 2020-04-02, This document is to define the YANG data model for shorter srv6( Compressing SRv6 ). "The Vulcain Protocol", Kevin Dunglas, 2020-04-03, 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, 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-20171026] 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. "Updates to the NNTP Protocol", Ekow Sam, 2020-04-03, This Internet Draft proposes and suggests updates to the Network News Transfer protocol, or NNTP. The NNTP powers Usenet, one of the largest social media platforms in the world. It is primarily used for transferring text and binary posts. The aim of these updates is to improve efficiency between NNTP peers and NNTP clients. "Alternative NTP port", Miroslav Lichvar, 2020-04-06, This document specifies an alternative port for the Network Time Protocol (NTP) which is restricted in modes in order to avoid amplification attacks. "Secure UAS Network RID and C2 Transport", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2020-04-06, 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. "Virtual Hum Application: Requirements", Yaron Sheffer, 2020-04-06, The IETF has been having virtual meetings for a long time. Until recently these have been interim meetings, and following the all- virtual IETF-107 we expect to see more and more WG meetings take the virtual route. A common practice at the IETF is to use room "humming" to gauge working group consensus, though the final consensus is determined by the working group chairs and typically requires a mailing list poll as well. We do not have a technique equivalent to the hum for virtual meetings, and arguably this reduces the effectiveness of these meetings. This document defines the requirements from a web application whose goal is to most faithfully replicate the "feel" of hums, through the use of a traditional web user interface. "QUIC Version Aliasing", Martin Duke, 2020-04-23, 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-04-06, 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-04-07, This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Type for encrypted DNS such as DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). "BGP Extensions to Support Packet Network Slicing in SR Policy", Liu Yao, Shaofu Peng, 2020-04-07, [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-04-09, [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.. "Supporting Redirect Responses in DNS Queries over HTTPS (DoH)", Mohamed Boucadair, Neil Cook, Tirumaleswar Reddy.K, Dan Wing, 2020-04-17, This document clarifies whether DNS-over-HTTPS (DoH) redirection is allowed and specifies how redirection is thus performed. "LTP Fragmentation", Fred Templin, 2020-04-10, The Licklider Transmission Protocol (LTP) provides a reliable datagram "covergence 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. This document discussses LTP interactions with IP fragmentation and mitigations for managing the amount of IP fragmentation employed. "YANG Model for RPKI VRPs", Job Snijders, 2020-04-10, This document describes a YANG model for a commonly used datastructure for RPKI Validated ROA Payload data. This specific datastructure is commonly used in the transport between RPKI Cache Validators and BGP routers. "Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission", Mohamed Boucadair, Jon Shallow, 2020-05-24, This document specifies new Constrained Application Protocol (CoAP) Block-Wise transfer options: Block3 and Block4 Options. These options are similar to the CoAP Block1 and Block2 Options, but 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. "Glue In DNS Referral Responses Is Not Optional", Mark Andrews, 2020-04-16, The DNS uses glue records to allow iterative clients to find the addresses of nameservers that live within the delegated zone. Glue records are expected to be returned as part of a referral and if they cannot be fitted into the UDP response, TC=1 MUST be set to inform the client that the response is incomplete and that TCP SHOULD be used to retrieve the full response. "Clearcast Identifier URN Namespace definition", Martin Roberts, 2020-04-15, Clearcast Clock Identifiers are used for the unique identification of television advertisement content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for Clearcast Identifiers. "BGP Maximum Prefix Limits Inbound", Job Snijders, Melchior Aelmans, stucchi-lists@glevia.com, 2020-04-15, 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-04-16, This document specifies ASN Label Switching Protocol (ALSP). "The CONNECT-UDP HTTP Method", David Schinazi, 2020-04-16, 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/DavidSchinazi/masque-drafts. "Invisible Canonical Name Implementation", Yaoyuan Chen, 2020-04-17, To accomplish the goal that not exposing redundant and unuseful CNAME chains in answers responded to clients, this document describes two new DNS resource records called "IDR" and "ADR" for hiding CNAME iterative process and better safety consideration. "Multicast Path MTU", tathagata nandy, Nitin Singla, 2020-04-19, 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. "EVPN Egress Protection", Yubao Wang, 2020-04-19, A fast reroute framework for egress node protection is specified by [RFC8679] . But it cannot be applied to VXLAN EVPN directly. This document specifies a mechanism to apply Egress Node Protection to VXLAN EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI routes. "RPL Storing Root Ack", Rahul Jadhav, 2020-04-20, 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-04-20, This document analyzes the problems caused by contentions and collisions on wireless medium between data packets and ACKs in WLAN and it proposes an optimized ACK mechanism that can minimize the intensity of ACK Frame in QUIC, improving the performance of transport layer connection. "Timing Parameters in the RPKI based Route Origin Validation Supply Chain", Randy Bush, Job Snijders, 2020-04-21, This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication, propagation, and use of RPKI ROV data in relying parties and routers. "The Problem Statement for Precise Transport Networking", Quan Xiong, Peng Liu, 2020-04-24, As described in [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-04-24, 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. "Timing Parameters in the RPKI based Route Origin Validation Supply Chain", Randy Bush, Jay Borkenhagen, Tim Bruijnzeels, Job Snijders, 2020-04-24, This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication of ROV data, their propagation, and their use in Relying Parties and routers. "Upgrading Communication from Stub Resolvers to DoT or DoH", Puneet Sood, Paul Hoffman, 2020-05-14, This document describes methods for a DNS stub resolver to upgrade its communications with a known recursive resolver to include encrytion using DoT or DoH. This protocol is designed for the scenario where the stub resolver already has the IP address of the recursive resolver. Other protocols under develpment address scenarios where the stub resolver wants to discover recursive resolvers that use DoT or DoH. This document does not cover such discovery. "DNS Resolver Information Self-publication", Puneet Sood, Paul Hoffman, 2020-05-14, This document describes methods for DNS resolvers to self-publish information about themselves. The information is returned as a JSON object. The names in this object are defined in an IANA registry that allows for light-weight registration. Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers. "Describing QUIC's Protocol Data Units with Augmented Packet Header Diagrams", Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2020-04-24, 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 packet header diagram language, and not as a contribution to the development of the QUIC protocol. "Recommendations for Forwarding Packets Marked with EXP/LU DSCPs in Diffserv Networks", Steven Blake, 2020-04-25, Some network operators implementing Diffserv are purported to remark some IP packets with non-zero DSCP values to the default DSCP value '000000' at their ingress network boundaries. This behavior is often not strictly necessary to protect an operator's network resources, and it impedes end-to-end experimentation of new differentiated services. This document recommends that Diffserv network operators refrain from remarking packets received with an EXP/LU DSCP value [RFC2474][RFC8436] that is not in use within the operator's network, and recommends that operators forward these packets at each Diffserv node (DS-node) using the Default "best-effort" PHB. "IPv4 Network Layer Reachability Information with IPv6 Next Hop Use Cases", Gyan Mishra, 2020-04-27, As Enterprises and Service Providers upgrade their brown field or green field core to an IPv6 transport such as an MPLS LDPv6 core or SRv6 core, 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 customers. IXPs (Internet Exchange points) are also facing IPv4 address depletion at their peering points, which are large Layer 2 transit backbones that service providers peer and exchange IPv4 and IPv6 (Network Layer Reachability Information) NLRI. Today these transit exchange points are dual stacked. One proposal to solve this issue is to use [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering completely using the concept of [RFC5565] softwire mesh framework. So now with the MP-BGP reach capability exchanged over IPv4 AFI over IPv6 next hop peer we can now advertise IPv4(Network Layer Reachability Information) NLRI over IPv6 peering using the [RFC5565] softwire mesh framework. Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). Historically the AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer Reachability Information (NLRI). [RFC5549] specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 Protocol. [RFC5549] defines the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. With this new MP-BGP capability exchange allows the BGP peering session to act as a pure transport to allow the session to carry Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) for both IPv4 and IPv6. 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 carrying both IPv4 and IPv6 Network Layer Reachability Information (NLRI). This document also provides a possible 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. "UAS Remote ID", Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov, 2020-05-05, This document describes using Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide registration discovery for 3rd-party ID assertion. Further, HHITs can also be used elsewhere in the UTM architecture to facilitate UAS communications. "In-band Network-Wide Telemetry", Tian Pan, Minglan Gao, Enge Song, Zizheng Bian, Xingchen Lin, 2020-04-28, 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 embed 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 member, reducing the overall telemetry overhead. INT- path is very suitable for deployment in data center networks thanks to their symmetric topologies. "OSCORE Implementation Guidance", Christian Amsuess, 2020-04-29, Object Security for Constrained RESTful Environments (OSCORE) is a means of end-to-end protection of short request/response exchanges for tiny devices, typically transported using the Constrained Application Protocol (CoAP). This document aims to assist implementers in leveraging the optimizations catered for by the combination of CoAP and OSCORE, and by generally providing experience from earlier implementations. "The ARK URI scheme", =?utf-8?q?Mario_Xerxes_Castel=C3=A1n_Castro_=28Ksenia=29?=, 2020-04-29, This specification defines the (ARK) URI scheme that is especially suitable for persistent identifiers. Persistent identifiers for latest version of this document: . "Automatic Certificate Management Environment (ACME) Onion v3 Identifier Validation Extension", Roland Shoemaker, 2020-04-29, This document specifies identifiers and challenges required to enable the Automatic Certificate Management Environment (ACME) to issue certificates for Onion Addresses as specified in Tor Rendezvous Specification - Version 3. "Channel Bindings for SCRAM over TLS 1.3", Sam Whited, 2020-05-04, This document defines a channel binding type, tls-scram-exporter, that is compatible with SCRAM [RFC5802] and TLS 1.3 [RFC8446] in accordance with On Channel Binding [RFC5056]. "JSResume: A JSON representation of resume data", Matt Dumler, 2020-05-01, This specification defines a data model and JSON representation of resume data that can be used for storage and data exchange in human resource and professional networking applications. "A Default Validation Policy for the use of RPKI Manifests in the global Internet Routing System.", Job Snijders, 2020-05-04, Manifests are a critical cornerstone to the global Resource Public Key Infrastructure (RPKI). RFC 6486 describes a validation decision tree which introduced the notion of 'local policy', creating space for ambiguity. This ambiguity has led to various RPKI implementations producing different output when presented with the same input, but also leads to severe operational security implications. This document updates RFC 6486 and introduces the notion of a default policy for Manifest validation to encourage harmony between implementations. "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-05-05, 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-05-15, 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, Samson Ninan, Mukul Srivastava, Nagendra Nainar, 2020-05-06, 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, 2020-05-08, This document specifies a mechanism, referred to as "service mapping", to express association of overlay routes with underlay routes using BGP. The document describes a framework for classifying underlay routes into transport planes, and mapping service routes to specific transport plane. It specifies BGP protocol procedures that enable dissimination of such service mapping information that may span across administrative domains. It makes it possible to advertise multiple tunnels to the same destination. A new BGP transport address family is defined for this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI encoding. This new address family is called "Classful Transport". "Announcing IPv4 routes with an IPv6 next-hop in the Babel routing protocol", Theophile Bastian, Juliusz Chroboczek, 2020-05-14, 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. "REM Remote Electron Microscopy", Vivekananda Katakam, 2020-05-08, This RFC document envisages the need and necessity in utilizing or extending the compute resource technologies in such as networking(NW), remote computing(RC),cloud computing(CC),distributed computing(DC), Machine Learning(ML) and other related fields of AI to the biological field of electron microscopy(EC) for use in rapid and timely identification or diagnosis of virological/bacterial elements in clinical samples in the current world scenario, within the given time frame irrespective of the place of origin and with having geographical presence. Electron microscopy (EM) is a pioneering methodology used in identification and diagnosing of viral and microbiological elements. It is able to identify in morphological form the tiniest of the viruses in minimum amount of time by clinical scientists. "Principles of the Request for Comments Series", Brian Carpenter, 2020-05-17, This document discusses the underlying principles of the Internet technical community's Request for Comments document Series. "Use Identity as Raw Public Key in EAP-TLS", chenmeiling, Li Su, HAIGUANG Wang, 2020-05-12, This document specifies the use of identity as a raw public key in EAP-TLS and EAP-TLS13, EAP-TLS defined in RFC 5216. The protocol procedures of EAP-TLS-IBS will comply with EAP-TLS and EAP-TLS13, Identity-based signature will be extended to support EAP-TLS's signature algorithms. "Efficient Implementation Method for Loop-free Criterion", Haijun Geng, Han Zhang, Xingang Shi, Zhiliang Wang, Xia Yin, 2020-05-12, [RFC5286] introduces Loop-Free Criterion (LFC) in detail, which is a technology for local fast rerouting when network failures occur. With LFC, alternate next hops are stored alongside with the default next hops in a routers forwarding table, and can be immediately activated to invoke a loop free repair path in face of link failure. As long as not introducing routing loops, these alternative next hops can also be used for multipath transmission if there are stringent demands on bandwidth or load balancing. However, in such link state networks, computing loop free alternates typically requires one or more rounds of full shortest path tree computation on a graph, and poses a heavy burden to both the processor load and the memory consumption of a network equipment. In this document, we describe an efficient Loop-free Criterion (LFC) implementation method which is based on incremental shortest path first (i-SPF), which is suitable for practical deployment in large scale networks. The computational complexity of the method is independent of the average node degree of the network. "Notable CBOR Tags", Carsten Bormann, 2020-05-15, 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 and its revision 7049bis define a basic set of tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, some 80 tag definitions have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to a IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. "End to End Media Encryption Procedures", Sergio Murillo, Alexandre Gouaillard, 2020-05-12, In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines a procedure to perform end to end media authenticated encryption. "Questions Arising Concerning In-Person Meeting Cancellation", Alissa Cooper, Russ Housley, Suresh Krishnan, 2020-05-13, The COVID-19 pandemic has required the IETF community to confront complicated questions about the cancellation and replacement of in- person meetings. This document lists some general questions that have come up for discussion in the community as the IESG, the IRTF Chair, and the IETF LLC have been faced with making decisions about IETF 107 and IETF 108. "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", Alexey Melnikov, 2020-05-14, This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. "The use cases of yang model conversion", Boyuan Yan, Zhuotong Li, Yongli Zhao, 2020-05-14, This document contains the brief description and the guidelines for the usage of Yang model conversion (YMC). It demonstrates the benefits of YMC for both communication vendors and network operators, provides several use cases to show the proper operations, and provides the recommendations for the development. "MAC Address for Layer 3 Link Local Discovery Protocol (LLDP)", Donald Eastlake, 2020-05-14, IEEE 802 has defined a number of protocols which operate between adjacent Ethernet stations at Layer 2, including bridges, such as the Link Layer Discover Protocol (IEEE 802.1AB, LLDP). LLDP and other such protocols may be useful between Layer 3 aware stations such as IP routers and hosts. This document specifies a MAC address that can be used for this purpose despite intervening bridges. "Anycast SID for Flexible and Robust Service in SRv6", Taixin Li, Zhe Chen, 2020-05-15, Segment Routing enables an operator or an application to specify a packet processing program. When Segment Routing is applied to IPv6 data plane, the list of IPv6 SIDs in SRH can specify a series of execution endpoints that hold service functions that process the packet. However, steering traffic dynamically to the different execution endpoints requires a specific "re-encapsulating". This procedure may be complex and take time. This document proposes A-SID (Anycast-SID) based on SRv6 to achieve flexible and robust service provision. It uses anycast SID to identify service functions and locates the service functions based on anycast routing. The proposed solution can stay compatibility with the existing SRv6. "YANG Model Conversion", Boyuan Yan, Zhuotong Li, Yongli Zhao, 2020-05-15, This document introduces the grammer extensions and relavant rules for YANG 1.0 [RFC6020] to complete the mapping between two similar YANG modules that describe the same entity. "Reduction of EVPN C-MAC Overload", Yubao(Bob) Wang, 2020-05-17, When there are too many customer-MACs (C-MACs), the RRs and/or ASBRs will be overloaded by the RT-2 routes for these MACs according to [I-D.dawra-bess-srv6-services]. This issue can be simply solved by making the remote C-MAC entries learnt via data-plane MAC learning (like what PBB VPLS have been done since [RFC7041]) rather than received from RT-2 routes. This simplified solution will works as well as PBB VPLS. But this simplified solution will lose many important features that based on the ESI concept. Because the ingress-ESI can't be learnt via data-plane MAC learning at the egress PE. So when the data packets is forwarded following these MAC entries, they can't benefit from the EAD/EVI routes as per RFC7432. So the All-Active Redundancy mode for ES can't be supported. This make the simplified solution can't work as well as PBB EVPN ([RFC7623]). This document proposes a new SRv6 function type and an extension to [I-D.dawra-bess-srv6-services] to achieve all-active mode ES redundancy on TPEs and reduce the C-MAC loads for RRs and ASBRs. The new solution will work even more better than PBB EVPN under the help of these extensions. "Need for integration of social media information retrieval statistics and GPS", pradeep xplorer, 2020-05-17, This document describes the need for integration of social media information retrieval statistics and GPS "Need for integration of social media information retrieval statistics and GPS", pradeep xplorer, 2020-05-17, This document describes the need for integration of social media information retrieval statistics and GPS "SBOM Extension for MUD", Eliot Lear, Scott Rose, 2020-05-18, Software bills of materials (SBOMs) are formal descriptions of what pieces of software are included in a product. This memo specifies a means for manufacturers to state how SBOMs may be retrieved through an extension to manufacturer usage descriptions (MUD). "IPv6 Compressed Routing Header with Variable Length Addresses", Fred Templin, 2020-05-18, The IPv6 Routing Header can be used to direct a packet through multiple intermediate IPv6 waypoints toward a final destination. In its simplest form, the routing header includes the full length of each intermediate IPv6 waypoint. This document specifies a method for supporting variable-length compressed IPv6 addresses. "Generalized SRv6 Network Programming for SRv6 Compression", Weiqiang Cheng, Zhenbin Li, Cheng Li, Francois Clad, Liu Aihua, Chongfeng Xie, Yisong Liu, Shay, 2020-05-19, 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-05-19, This informational draft documents the lispers.net LISP NAT-Traversal implementation. "Defined Resource Operator (drop) The 'drop' URI Scheme", Tim McSweeney, 2020-05-22, 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, Jim Guichard, Liu Aihua, 2020-05-19, 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. "SRv6 SID MPLS", Taixin Li, Zhe Chen, 2020-05-19, Segment Routing is good. "Secure Frame (SFrame)", Emad Omara, Justin Uberti, Alexandre Gouaillard, Sergio Murillo, 2020-05-19, 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. "Signalling Authoritative DoT support in DS records, with key pinning", Peter van Dijk, Robin Geuze, Emmanuel Bretelle, 2020-05-19, This document specifies a way to signal the usage of DoT, and the pinned keys for that DoT usage, in authoritative servers. This signal lives on the parent side of delegations, in DS records. To ensure easy deployment, the signal is defined in terms of (C)DNSKEY. "A Framework For Decentralized Bearer Token Issuance in HTTP", Michael Thornburgh, 2020-05-19, 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. "An Upgrade to Benchmarking Methodology for Network Interconnect Devices", Gabor Lencse, Keiichi Shima, 2020-05-20, RFC 2544 has defined a benchmarking methodology for network interconnect devices. We recommend a few upgrades to it for producing more reasonable results. The recommended upgrades can be classified into two categories: the application of the novelties of RFC 8219 for the legacy RFC 2544 use cases and the following new ones. Checking a reasonably small timeout individually for every single frame in the throughput and frame loss rate benchmarking procedures. Performing a statistically relevant number of tests for all benchmarking procedures. Addition of an optional non-zero frame loss acceptance criterion for the throughput measurement procedure and defining its reporting format. "Usage Limits on AEAD Algorithms", Felix Gunther, Martin Thomson, Christopher Wood, 2020-05-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. "Adaptive DNS Resolver Discovery", Tommy Pauly, Eric Kinnear, Christopher Wood, Patrick McManus, Tommy Jensen, 2020-05-20, This document defines a method for dynamically discovering resolvers that support encrypted transports, and introduces the concept of a designating a resolver to be used for a subset of client queries based on domain. This method is intended to work both for locally- hosted resolvers and resolvers accessible over the broader Internet. "Internet Protocol Encapsulation of AX.25 Frames", Iain Learmonth, 2020-05-21, 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 "Optimal Retrieval Process for DNS Based on EDNS", Daobiao Gong, Peng Zhang, 2020-05-21, This document specifies a mechanism for query-response protocol to improve DNS retrieval efficiency,which makes the resolver always look for the best authoritative servers to ask for the required data.Based on the extension mechanisms for DNS,optimal-result using OPT pseudo- RR can be added to the addtional data section of either a request or a response,which contains the information of optimal authoritative servers by testing. "DNS Authoritative server Management Based on Blockchain", Yang Song, louie long, 2020-05-21, This document specifies a mechanism for managing authoritative server such as root server,thereby implement decentralized management of the authoritative server.Through distributed decision and distributed storage,encrypted inforamtion and records are stored adding the block to the blockchain.And the distributed authoritative servers share common blockchain which has detailed retrieval data for answering queries from the resolvers. "The GNU Name System", Martin Schanzenbach, Christian Grothoff, Bernd Fix, 2020-05-24, This document contains the GNU Name System (GNS) technical specification. "Changes to the RFC Series and RSE", Nevil Brownlee, 2020-05-24, This document discusses the impact of changes to the RFC Series on the RFC Production Centre, and the need for the RFC Series Editor to be independent of the Series Input Streams (the I* groups). "IoT Edge Computing: Initiatives, Projects and Products", Xavier de Foy, Jungha Hong, Yong-Geun Hong, Matthias Kovatsch, Eve Schooler, Dirk Kutscher, 2020-05-25, Many IoT applications have requirements that cannot be met by the traditional Cloud. As a result, the IoT is driving the Internet toward Edge computing. This draft reviews initiatives, projects and products related to IoT Edge Computing. Network Time Protocol (ntp) --------------------------- "Network Time Security for the Network Time Protocol", Daniel Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie, Ragnar Sundblad, 2020-03-25, This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS-KE) handles initial authentication and key establishment over TLS. The second handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies. "Control Messages Protocol for Use with Network Time Protocol Version 4", Brian Haberman, 2019-11-19, 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 a current, but historic, description of the control messages as described in RFC 1305 and any additional commands implemented in NTP. The publication of this document is not meant to encourage the developement 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-01-22, This document defines a YANG data model for Network Time Protocol (NTP) implementations. The data model includes configuration data and state data. "Guidelines for Defining Packet Timestamps", Tal Mizrahi, Joachim Fabini, Alfred Morton, 2020-03-11, Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as packet timestamps for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The targe