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 2019-10-22 05:08:00 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, 2019-09-26, 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 MultiLink Subnet. "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk, 2019-09-28, 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, 2019-04-10, This document specifies an extension to 6LoWPAN Neighbor Discovery (ND) protocol defined in RFC6775 and updated in RFC8505. 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. "IPv6 over Constrained Node Networks (6lo) Applicability & Use cases", Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita Chakrabarti, 2019-09-10, This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, and PLC (IEEE 1901.2) are used as examples. The document targets an audience who like to understand and evaluate running end-to-end IPv6 over the constrained node networks connecting devices to each other or to other devices on the Internet (e.g. cloud infrastructure). "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, 2019-10-21, This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat. "6LoWPAN Fragment Forwarding", Thomas Watteyne, Carsten Bormann, Pascal Thubert, 2019-09-02, This document provides a simple method to forwarding 6LoWPAN fragments. 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 always been possible with the original fragmentation design of RFC4944. This method reduces the latency and increases end-to-end reliability in route-over forwarding. It is the companion to the virtual Reassembly Buffer which is a pure implementation technique. IPv6 Maintenance (6man) ----------------------- "IPv6 Segment Routing Header (SRH)", Clarence Filsfils, Darren Dukes, Stefano Previdi, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca, 2019-10-10, Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header. This document describes the Segment Routing Header and how it is used by Segment Routing capable nodes. "ICMPv6 errors for discarding packets due to processing limits", Tom Herbert, 2019-09-30, 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 be able to modify what it sends in future packets to avoid subsequent packet discards. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves, 2019-09-05, Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. 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 makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. This document formally obsoletes RFC4941. "Discovering PREF64 in Router Advertisements", Lorenzo Colitti, Jen Linkova, 2019-10-03, This document specifies a Router Advertisement option to communicate NAT64 prefixes to hosts. "Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)", Zafar Ali, Clarence Filsfils, Satoru Matsushima, daniel.voyer@bell.ca, Mach Chen, 2019-08-08, 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, 2019-09-13, 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. 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-18, 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. "Minimal Security Framework for 6TiSCH", Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson, 2019-07-29, 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 configures 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. "6tisch Zero-Touch Secure Join protocol", Michael Richardson, 2019-07-08, This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator. The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and is a profile of the constrained voucher mechanism [I-D.ietf-anima-constrained-voucher]. "IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information", Diego Dujovne, Michael Richardson, 2019-09-16, In TSCH mode of IEEE STD 802.15.4 opportunities for broadcasts are limited to specific times and specific channels. Nodes in a TSCH network typically frequently send Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which small details critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon. "6TiSCH Minimal Scheduling Function (MSF)", Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne, 2019-10-17, 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 builds 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, 2019-03-27, 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 CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz, 2019-04-12, This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS 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. "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", Michael Jones, Ludwig Seitz, Goeran Selander, Samuel Erdtman, Hannes Tschofenig, 2019-10-18, This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", Francesca Palombini, Ludwig Seitz, Goeran Selander, Martin Gunnarsson, 2019-07-08, 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, 2019-10-01, 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, 2019-03-25, This specification defines new parameters 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 whishes to use, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. "Key Provisioning for Group Communication using ACE", Francesca Palombini, Marco Tiloca, 2019-07-05, 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, 2019-07-05, This document describes a method to request and provision keying material in group communication scenarios where the group communication is based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific transport profiles of ACE to achieve communication security, proof-of-possession and server authentication. "MQTT-TLS profile of ACE", Cigdem Sengul, Anthony Kirby, Paul Fremantle, 2019-10-05, This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) 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 server authentication. Automated Certificate Management Environment (acme) --------------------------------------------------- "CAA Record Extensions for Account URI and ACME Method Binding", Hugo Landau, 2019-06-20, The Certification Authority Authorization (CAA) DNS record allows a domain to communicate issuance policy to Certification Authorities (CAs), but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required. "Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)", Yaron Sheffer, Diego Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati, 2019-10-13, Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. "Extensions to Automatic Certificate Management Environment for end user S/MIME certificates", Alexey Melnikov, 2019-07-08, 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. "ACME IP Identifier Validation Extension", Roland Shoemaker, 2019-10-01, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. "ACME TLS ALPN Challenge Extension", Roland Shoemaker, 2019-10-01, This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS. "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock, Mary Barnes, Jon Peterson, 2019-09-30, 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. "An ACME Profile for Generating Delegated STAR Certificates", Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2019-08-26, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2019-07-23, 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. For example, an ALTO server can provide network and cost maps so that an ALTO client can use the maps to determine the costs between network endpoints when choosing communicating endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to the information resources, other than by periodically re-fetching them. Because some information resources (e.g., the aforementioned maps) may be large (potentially tens of megabytes), and because only parts of the information resources may change frequently (e.g., only some entries in a cost map), complete re-fetching can be extremely inefficient. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be immediate, in that the ALTO server can send updates as soon as they are available; and (2) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes. "ALTO Cost Calendar", Sabine Randriamasy, Y. Yang, Qin WU, Deng Lingli, Nico Schwan, 2019-09-13, 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, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2019-07-08, Cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and is used in basic services including both the cost map service and the endpoint cost service. Different applications may use different cost metrics, but the ALTO base protocol documents only one single cost metric, i.e., the generic "routingcost" metric; see Sec. 14.2 of ALTO base specification [RFC7285]. Hence, if the resource consumer of an application prefers a resource provider that offers low-delay delivery 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, hop count, and bandwidth. These metrics can be derived and aggregated 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. Additional cost metrics may be documented in other documents. "Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery", Sebastian Kiesel, Martin Stiemerling, 2019-08-20, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix. "ALTO Extension: Path Vector", Kai Gao, Young Lee, Sabine Randriamasy, Y. Yang, J. Zhang, 2019-07-22, This document defines an ALTO extension that allows a resource to provide not only preferences of network paths but also correlations of network paths, including aggregations of network components and their properties on the paths between different PIDs or endpoints. The extended information can be used to improve the robustness and performance for applications in some new usage scenarios, such as high-speed data transfers and traffic optimization using in-network storage and computation. This document introduces abstract network element (ANE) as an abstraction for aggregations of network components. It extends the base protocol and the Unified Property extension to enable the capability of encoding such information in a "path vector", i.e., an array of ANEs that are traversed by traffic from a source to a destination. "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Y. Yang, Kevin Ma, Jon Peterson, Xiao Lin, Jingxuan Zhang, 2019-08-14, 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. In this document, we follow the guidelines to define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol. "Unified Properties for the ALTO Protocol", Wendy Roome, Sabine Randriamasy, Y. Yang, J. Zhang, Kai Gao, 2019-09-04, 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, 2019-07-22, Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and 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, 2019-09-19, This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. 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 lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to 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, 2019-10-06, 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, 2019-07-08, 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. 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. "Resolving Multiple Time Scales in the Internet", Joseph Touch, 2019-09-12, Internet systems use a variety of time scales, which can complicate time comparisons and calculations. This document explains these various ways of indicating time and explains how they can be used together safely. This document is intended as a companion to Internet time as discussed in RFC 3339. "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]. "IDNA2008 and Unicode 11.0.0", Patrik Faltstrom, 2019-03-11, This document describes the changes between Unicode 6.3.0 and Unicode 11.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 11.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. "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. "IDNA Review for New Unicode Versions", John Klensin, Patrik Faltstrom, 2019-09-26, The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and clarify the various relationships involved. It also makes other minor adjustments to align that document with experience. 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, 2019-07-22, 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, Jonathan Lennox, Danny Hong, 2019-07-24, 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, 2019-07-08, 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, 2019-09-27, 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 the TETRA Audio Codec", Andreas Reisenbauer, Udo Brandhuber, Joachim Hagedorn, Klaus-Peter Hohnsch, Stefan Wenk, 2019-07-26, This document specifies a Real-time Transport Protocol (RTP) payload format for TETRA encoded speech signals. The payload format is designed to be able to interoperate with existing TETRA transport formats on non-IP networks. A media type registration is included, specifying the use of the RTP payload format and the storage format. "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Sebastien Lugan, Gael Rouvroy, Antonin Descampe, Thomas Richter, Alexandre Willeme, 2019-10-09, 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 for TTML Timed Text", James Sandford, 2019-10-08, This memo describes a Real-time Transport Protocol (RTP) payload format for TTML, an XML based timed text format for live and file based workflows from W3C. This payload format is specifically targeted at live workflows using TTML. 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, 2019-10-18, 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, 2019-10-18, This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. "Delay-based Metric Extension for the Babel Routing Protocol", Baptiste Jonglez, Juliusz Chroboczek, 2019-04-26, This document defines an extension to the Babel routing protocol that uses symmetric delay in metric computation and therefore makes it possible to prefer lower latency links to higher latency ones. BGP Enabled ServiceS (bess) --------------------------- "BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro, 2019-07-26, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. "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, Gregory Mirsky, 2019-08-29, 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. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, Ing-Wher Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula, 2019-07-02, This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. This document also describes the YANG data model for the Pseudowires. The independent definition of the Pseudowires facilitates its use in Ethernet Segment and EVPN data models defined in separate document. "PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Masahiro Miyake, Taku Matsuda, 2019-07-26, Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) to deploy ELAN services in very large MPLS networks (PBB- EVPN). Single-Active Multi-homing and per-ISID Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a CMAC-Flush mechanism that works for different Ethernet Segment BMAC address allocation models. This document complements those CMAC-Flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (ESI 0) and an ISID-based CMAC-Flush granularity is desired. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2019-08-09, 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-08-20, 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, 2019-09-30, 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-06-25, 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, 2019-08-21, 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. "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2019-08-16, Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain. "MVPN and MSDP SA Interoperation", Zhaohui Zhang, Leonard Giuliano, 2019-10-16, This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source Active routes and customer Multicast Source Discovery Protocol (MSDP) Source Active routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the PEs that are customer MSDP peers. This document updates RFC6514. "EVPN VPWS Flexible Cross-Connect Service", Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Wen Lin, Sami Boutros, Jorge Rabadan, 2019-06-06, This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as flexible cross-connect service. It also describes the rational for this new service type as well as a solution to deliver such service. "Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing", Neeraj Malhotra, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, Avinash Lingala, 2019-07-22, 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 "EVPN Operations, Administration and Maintenance Requirements and Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald Eastlake, 2019-07-08, This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. "EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, 2019-09-02, 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, 2019-06-19, 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, Gregory Mirsky, 2019-05-22, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data-plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. "EVPN control plane for Geneve", Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan, Sam Aldrin, 2019-08-07, This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets. "PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Masahiro Miyake, Taku Matsuda, 2019-10-15, Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) to deploy ELAN services in very large MPLS networks (PBB- EVPN). Single-Active Multi-homing and per-ISID Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a CMAC-Flush mechanism that works for different Ethernet Segment BMAC address allocation models. This document complements those CMAC-Flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (ESI 0) and an ISID-based CMAC-Flush granularity is desired. "SRv6 BGP based Overlay services", Gaurav Dawra, Clarence Filsfils, Patrice Brissette, Swadesh Agrawal, John Leddy, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Dirk Steinberg, Robert Raszuk, Bruno Decraene, Satoru Matsushima, Shunwan Zhuang, Jorge Rabadan, 2019-10-16, 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". 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, Juniper Networks, Gregory 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-06-04, 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, 2019-08-26, 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, 2019-08-26, This document describes a security enhancements for the BFD packet's sequence number. "BFD for VXLAN", Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Gregory Mirsky, 2019-05-17, This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network. "BFD Encapsulated in Large Packets", Jeffrey Haas, Albert Fu, 2019-08-26, The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. "Unsolicited BFD for Sessionless Applications", Enke Chen, Naiming Shen, Robert Raszuk, Reshad Rahman, 2019-06-28, For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). Bit Indexed Explicit Replication (bier) --------------------------------------- "BIER Use Cases", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya, Caitlin Bestler, 2019-08-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. "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, 2019-09-06, Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information. These extensions are applicable in those multi-tenant data centers where BGP instead of IGP is deployed as an underlay for network reachability advertisement. These extensions may also be applicable in other scenarios. "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Santosh Pallagatti, 2019-08-27, 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", Gregory Mirsky, Tony Przygienda, Andrew Dolganow, 2019-06-04, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola, 2019-07-01, This document describes a hybrid performance measurement method for multicast service through a Bit Index Explicit Replication domain. "BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Gregory Mirsky, 2019-04-24, 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, 2019-05-20, 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, 2019-05-09, 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 advertising 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, 2019-07-08, 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. "Traffic Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless Eckert, Gregory Cauchie, Michael Menth, 2019-07-08, This memo introduces per-packet stateless strict and loose path engineered replication and forwarding for Bit Index Explicit Replication packets ([RFC8279]). This is called BIER-TE. BIER-TE leverages the BIER architecture ([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 (route) adjacencies. The BFR then replicates and forwards BIER packets to those adjacencies. This results in the aforementioned strict and loose path forwarding. BIER-TE can co-exist with BIER forwarding in the same domain, for example by using seperate 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 IGP routing protocol. BIER-TE operates without explicit in-network tree-building and carries the multicast distribution tree in the packet header. It can therefore be a good fit to support multicast path steering in Segment Routing (SR) networks. "PIM Signaling Through BIER Core", Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, mankamana mishra, Zhaohui Zhang, 2019-04-23, 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 switched on in BIER packet header. This document describes the procedure needed for PIM Joins and Prunes to be signaled through a BIER core. Allowing PIM routers to run traditional PIM multicast services through a BIER core. "BIER Underlay Path Calculation Algorithm and Constraints", Zhaohui Zhang, Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands, Arkadiy Gulko, 2019-08-09, This document specifies general rules for interaction between the BAR (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ OSPFv2 Extensions for BIER. The semantics for the BAR and IPA fields (when both or any of them is non-zero) defined in this document updates the semantics defined in RFC8444/RFC8401. "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", IJsbrand Wijnands, Xiaohu Xu, Hooman Bidgoli, 2019-08-09, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value. "Use of BIER Entropy for Data Center Clos Networks", Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride, 2019-05-07, Bit Index Explicit Replication (BIER) introduces a new multicast- specific BIER Header. BIER can be applied to the Multi Protocol Label Switching (MPLS) data plane or Non-MPLS data plane. Entropy is a technique used in BIER to support load-balancing. This document examines and describes how BIER Entropy is to be applied to Data Center Clos networks for path selection. "BIER Penultimate Hop Popping", Zhaohui Zhang, 2019-10-03, Bit Index Explicit Replication (BIER) can be used as provider tunnel for Multicast Virtual Private Network (MVPN) [RFC6514], Global Table Multicast [RFC7716] or Ethernet Virtual Private Network (EVPN) [RFC7432]. It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER incapable transit routers. However those methods assume the MVPN/ EVPN Provider Edges (PEs) are BIER capable. This document specifies a method to allow BIER incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BIER Forwarding Router (BFR) that is connected directly or indirectly via a tunnel to a BIER incapable PE remove the BIER header and send the payload to the PE. "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Dirk Trossen, Akbar Rahman, Chonggang Wang, Toerless Eckert, 2019-06-28, 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 IPMC, 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, 2019-05-21, 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 Kumar, IJsbrand Wijnands, 2019-05-23, 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, 2019-07-01, The BIER WG has a charter item to work on mechanisms which use 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 and summarize the pro's and con's of the proposed solutions. "LSR Extensions for BIER over Ethernet", Senthil Dhanaraj, IJsbrand Wijnands, Peter Psenak, Zhaohui Zhang, Gang Yan, Jingrong Xie, 2019-07-08, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore Tiruveedhula, 2019-08-21, 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, Brian Monkman, 2019-09-03, 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, 2019-07-04, 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, 2019-10-15, This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative, and over time successor to, the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. "JSCalendar: Converting from and to iCalendar", Neil Jenkins, Robert Stepanek, 2019-06-29, This document provides an informational guideline for converting JSCalendar from and to iCalendar. "Calendar subscription upgrades", Michael Douglass, 2019-06-07, This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol. This specification updates [RFC5545] to add the value DELETED to the STATUS property. This specification also updates [RFC7240] to add the subscribe- enhanced-get and limit preferences. "VALARM Extensions for iCalendar", Cyrus Daboo, Ken Murchison, 2019-06-10, 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, 2019-06-29, This document aims to document consensus on the 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, 2019-07-06, This document describes an HTTP API that allows clients to interact with a Captive Portal system. "Captive-Portal Identification in DHCP / RA", Warren Kumari, Erik Kline, 2019-07-02, 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 DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal 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 used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. 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, 2019-08-25, 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 Typed Arrays", Carsten Bormann, 2019-10-08, 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. The present document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as two additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. "Concise Binary Object Representation (CBOR) Sequences", Carsten Bormann, 2019-09-25, This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. 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, 2019-09-08, 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 framework for Management and Control of DWDM optical interface parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, Julien Meuric, 2019-07-24, The control and management of DWDM interfaces are a precondition for enhanced multilayer networking. They are needed to ensure an efficient data transport, to meet the requirements requested by today's IP-services and to provide a further automation of network provisioning and operations. This document describes use cases, requirements and solutions for the control and management of optical interface parameters according to different types of single channel DWDM interfaces. The focus is on automating the network provisioning process irrespective on how it is triggered i.e. by Element Manager System (EMS), Network Management System (NMS) or Generalized Multi Protocol Label Switching (GMPLS). This document covers management and control considerations in different scenarios of single channel DWDM interfaces. The purpose is to identify the necessary information and processes to be used by control or management systems to properly and efficiently drive the network. "A YANG Data Model for WSON (Wavelength Switched Optical Networks)", Young Lee, Dhruv Dhody, Aihua Guo, Victor Lopezalvarez, Daniel King, 2019-07-05, 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 defined in RFC 8342. "A YANG Data Model for Optical Transport Network Topology", Haomian Zheng, Aihua Guo, Italo Busi, Anurag Sharma, Xufeng Liu, Sergio Belotti, Yunbin Xu, Lei Wang, Oscar de Dios, 2019-09-29, 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, Aihua Guo, Italo Busi, Anurag Sharma, Rajan Rao, Sergio Belotti, Victor Lopezalvarez, Yunbo Li, Yunbin Xu, 2019-07-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, 2019-07-07, 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, 2019-09-11, This document provides a YANG data model for WSON TE tunnel. "Transport Northbound Interface Applicability Statement", Italo Busi, Daniel King, Haomian Zheng, Yunbin Xu, 2019-09-12, Transport network domains, including Optical Transport Network (OTN) and Wavelength Division Multiplexing (WDM) networks, are typically deployed based on a single vendor or technology platforms. They are often managed using proprietary interfaces to dedicated Element Management Systems (EMS), Network Management Systems (NMS) and increasingly Software Defined Network (SDN) controllers. A well-defined open interface to each domain management system or controller is required for network operators to facilitate control automation and orchestrate end-to-end services across multi-domain networks. These functions may be enabled using standardized data models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). This document analyses the applicability of the YANG models being defined by the IETF (Traffic Engineering Architecture and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) WGs in particular) to support OTN single and multi-domain scenarios. "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee, Kwang-koog Lee, Haomian Zheng, Dhruv Dhody, Oscar de Dios, Daniele Ceccarelli, 2019-09-09, 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, 2019-07-07, 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 support of OTU/ODU links with rates larger than 100G in the 2016 version of G.709. "A YANG model to manage the optical interface parameters for an external transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel, 2019-07-08, 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, Luc Auge, Dieter Beller, 2019-05-27, 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, 2019-10-17, 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 Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and Spectrum Switched optical Networks (SSONs). The applicability of this document is mainly for TE, but not limited to. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC8342. "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, 2019-05-27, 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, 2019-09-09, 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-09-24, Open Caching is a use case of Content Delivery Networks Interconnetion (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 and FCI interfaces 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, 2019-05-29, 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, 2019-09-24, 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 CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of 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, 2019-10-21, This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. 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, 2019-10-10, 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, 2019-10-10, 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 Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice, 2019-07-22, This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application. "Matroska Codec", Steve Lhomme, Moritz Bunkus, Dave Rice, 2019-07-22, 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 Tags", Steve Lhomme, Moritz Bunkus, Dave Rice, 2019-07-22, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. "Free Lossless Audio Codec", Josh Coalson, , Andrew Weaver, 2019-07-30, This document defines FLAC, which stands for Free Lossless Audio Codec, a free, open source codec for lossless audio compression and decompression. Crypto Forum (cfrg) ------------------- "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2019-10-03, 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, 2019-10-10, 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-05-21, 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, 2019-08-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, 2019-09-07, Randomness is a crucial ingredient for 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 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. "Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick Sullivan, Riad Wahby, Christopher Wood, 2019-07-08, 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. "The ristretto255 Group", Henry de Valence, Jack Grigg, George Tankersley, Filippo Valsorda, Isis Lovecruft, 2019-05-08, This memo specifies a prime-order group, ristretto255, suitable for implementing complex cryptographic protocols such as zero-knowledge proofs. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. "Pairing-Friendly Curves", Shoko Yonezawa, Tetsutaro Kobayashi, Tsunekazu Saito, 2019-07-08, This memo introduces pairing-friendly curves used for constructing pairing-based cryptography. It describes recommended parameters for each security level and recent implementations of pairing-friendly curves. "XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305", Scott Arciszewski, 2019-07-22, 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 [RFC7539] that utilizes the XChaCha20 construction in place of ChaCha20. "Hybrid Public Key Encryption", Richard Barnes, Karthikeyan Bhargavan, 2019-07-04, 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, 2019-07-24, 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, Giles Van Assche, Quynh Dang, Joan Daemen, 2019-08-06, 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-00.txt", Dan Boneh, Riad Wahby, Sergey Gorbunov, Hoeteck Wee, Zhenfei Zhang, 2019-08-12, BLS is a digital signature scheme with compression properties. With a given set of signatures (signature_1, ..., signature_n) anyone can produce a compressed signature signature_compressed. The same is true for a set of secret keys or public keys, while keeping the connection between sets (i.e., a compressed public key is associated to its compressed secret key). 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. 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, 2018-10-22, 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, 2019-07-08, 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, 2019-09-11, 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]. "Dynamic Resource Linking for Constrained RESTful Environments", Zach Shelby, Michael Koster, Christian Groves, Jintao Zhu, Bill Silverajan, 2019-07-22, This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). This specification also defines Conditional Notification Attributes that work with Link Bindings or with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2019-09-30, The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. There is work in progress to resolve some of the transfer layer issues by using a more RESTful approach. Please see https://github.com/core-wg/pubsub/blob/master/proposal.txt "YANG Schema Item iDentifier (SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, 2019-07-08, YANG Schema Item iDentifiers (SID) are globally unique 64-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, 2019-09-27, 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. "CoRE Resource Directory: DNS-SD mapping", Peter van der Stok, Michael Koster, Christian Amsuess, 2019-07-07, Resource and service discovery are complementary. Resource discovery provides fine-grained detail about the content of a web server, while service discovery can provide a scalable method to locate servers in large networks. This document defines a method for mapping between CoRE Link Format attributes and DNS-Based Service Discovery records to facilitate the use of either method to locate RESTful service interfaces (APIs) in heterogeneous HTTP/CoAP environments. "CoAP: Echo, Request-Tag, and Token Processing", Christian Amsuess, John Mattsson, Goeran Selander, 2019-09-19, This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. 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, 2019-07-05, This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. In particular, it defines how OSCORE is used in a group communication setting, while fulfilling the same security requirements for group requests and responses. Source authentication of all messages exchanged within the group is provided by means of digital signatures produced by the sender and embedded in the protected CoAP messages. "Multipart Content-Format for CoAP", Thomas Fossati, Klaus Hartke, Carsten Bormann, 2019-08-21, This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. "Constrained Application Protocol (CoAP) Hop-Limit Option", Mohamed Boucadair, Reddy K, Jon Shallow, 2019-10-17, The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. "FETCH & PATCH with Sensor Measurement Lists (SenML)", Ari Keranen, Mojan Mohajer, 2019-08-17, 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 iPATCH, PATCH, and FETCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model. "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", Klaus Hartke, 2019-10-21, 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, 2019-07-24, This document describes a constrained version of the YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a constrained network management server (e.g., a CORECONF server). "SenML Data Value Content-Format Indication", Ari Keranen, Carsten Bormann, 2019-08-29, The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values this document proposes to specify a new SenML field for indicating the Content-Format of the data. "The Constrained RESTful Application Language (CoRAL)", Klaus Hartke, 2019-08-29, 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"), as well as simple resource metadata. "Constrained Resource Identifiers", Klaus Hartke, 2019-08-29, Constrained Resource Identifiers (CoRIs) are an alternate serialization of Uniform Resource Identifiers (URIs) that encodes the URI components in Concise Binary Object Representation (CBOR) instead of a string of characters. This simplifies parsing, reference resolution, and comparison of URIs in environments with severe limitations on processing power, code size, and memory size. "Additional Units for SenML", Carsten Bormann, 2019-10-12, 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; RFC 8428 is updated to also accept these units. CBOR Object Signing and Encryption (cose) ----------------------------------------- "Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", Russ Housley, 2019-10-10, This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. "CBOR Object Signing and Encryption (COSE): Structures and Process", Jim Schaad, 2019-09-11, 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, 2019-09-11, 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): Headers for carrying and referencing X.509 certificates", Jim Schaad, 2019-09-12, 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, 2019-06-10, The CBOR Object Signing and Encryption (COSE) syntax RFC 8152 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 external contents are signed, or thumbprints, for identification of X.509 certificates or other objects. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. "COSE and JOSE Registrations for WebAuthn Algorithms", Michael Jones, 2019-07-08, The W3C Web Authentication (WebAuthn) specification and the FIDO2 Client to Authenticator Protocol (CTAP) specification use COSE algorithm identifiers. This specification registers algorithms in the IANA "COSE Algorithms" registry that are used by WebAuthn and CTAP implementations that are not already registered. Also, they are registered in the IANA "JSON Web Signature and Encryption Algorithms" registry, when not already registered there. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448", Aris Adamantiadis, Simon Josefsson, Mark Baushke, 2019-09-05, This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. "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. "GSS-API Key Exchange with SHA2", Simo Sorce, Hubert Kario, 2019-07-23, This document specifies additions and amendments to RFC4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. "Deprecating RC4 in Secure Shell (SSH)", Luis Camara, Loganaden Velvindron, 2019-07-31, This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves to Historic RFC4345. "Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH) protocol", Ben Harris, Loganaden Velvindron, 2019-09-09, This document describes the use of the Ed25519 and Ed448 digital signature algorithm in the Secure Shell (SSH) protocol. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking Architecture", Norman Finn, Pascal Thubert, Balazs Varga, Janos Farkas, 2019-05-06, This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower layer technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). "Deterministic Networking (DetNet) Security Considerations", Tal Mizrahi, Ethan Grossman, Andrew Hacker, Subir Das, John Dowdell, Henrik Austad, Kevin Stanton, Norman Finn, 2019-08-29, A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 8. "DetNet Flow Information Model", Janos Farkas, Balazs Varga, Rodney Cummings, Yuanlong Jiang, Don Fedyk, 2019-09-12, 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, 2019-07-08, 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, Don Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-09-13, This document provides an overall framework for the Deterministic Networking data plane. It covers concepts and considerations that are generally common to any Deterministic Networking data plane specification. "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-05-06, This document specifies the Deterministic Networking data plane when TSN networks interconnected over an MPLS Packet Switched Networks. "DetNet Data Plane: MPLS over UDP/IP", Balazs Varga, Janos Farkas, Lou Berger, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-10-16, 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, Jouni Korhonen, 2019-05-06, This document specifies the Deterministic Networking MPLS data plane when operating over a TSN network. "DetNet Data Plane: MPLS", Balazs Varga, Janos Farkas, Lou Berger, Don Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-10-16, 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, Jouni Korhonen, 2019-05-06, This document specifies the Deterministic Networking IP data plane when operating over a TSN network. "DetNet Data Plane: IP over MPLS", Balazs Varga, Janos Farkas, Lou Berger, Don Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-10-16, 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, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-10-16, This document specifies the Deterministic Networking data plane when operating in an IP packet switched network. "DetNet Bounded Latency", Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas, 2019-07-24, This document presents a timing model for Deterministic Networking (DetNet), so that existing and future standards can achieve the DetNet quality of service features of bounded latency and zero congestion loss. It defines requirements for resource reservation protocols or servers. It calls out queuing mechanisms, defined in other documents, that can provide the DetNet quality of service. Dynamic Host Configuration (dhc) -------------------------------- "YANG Data Model for DHCPv6 Configuration", Yong Cui, Linhui Sun, Ian Farrer, Sladjana Zechlin, Zihao He, 2019-09-09, This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays, and clients. "Link-Layer Addresses Assignment Mechanism for DHCPv6", Bernie Volz, Tomek Mrugalski, Carlos Bernardos, 2019-09-20, 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, 2019-07-08, 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. In this document, we complement this ongoing IETF 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 address to the given client out of the quadrant requested by relay or client. "Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Ren Gang, Lin He, Ying Liu, 2019-10-11, The manageability, security, privacy protection, and traceability of networks can be supported by extending DHCPv6 protocol according to requirements. This document analyzes current extension practices and typical DHCP server software on extensions, defines a DHCP general model, discusses some extension points, and present extension cases. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2018-12-28, 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", Myles Borins, Mathias Bynens, Matthew Miller, Bradley Farias, 2019-06-19, This document proposes updates to the ECMAScript media types, superseding the existing registrations for "application/javascript" and "text/javascript" by adding an additional extension and removing usage warnings. This document updates RFC4329, "Scripting Media Types". Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Recommended Usage of the Authenticated Received Chain (ARC)", Steven Jones, Kurt Andersen, 2019-04-23, The Authentication 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, 2019-10-14, 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) ------------------------------------- "On Demand Mobility Management", Alper Yegin, Danny Moses, Seil Jeon, 2019-07-31, Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in [RFC7333]. This document defines a new concep of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-Socket basis, and suggests extensions to the networking stack's API to accomodate this concept. "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Carlos Bernardos, 2019-03-26, 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. "Segment Routing IPv6 for Mobile User Plane", Satoru Matsushima, Clarence Filsfils, Miya Kohno, Pablo Camarillo, daniel.voyer@bell.ca, Charles Perkins, 2019-09-26, This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing and SLA control for various applications. This document describes the SRv6 mobile user plane behavior and defines the SID functions for that. "Proxy Mobile IPv6 extensions for Distributed Mobility Management", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, Juan Zuniga, Alain Mourad, 2019-01-29, 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. "User Plane Protocol and Architectural Analysis on 3GPP 5G System", Shunsuke Homma, Takuya Miyasaka, Satoru Matsushima, daniel.voyer@bell.ca, 2019-07-08, This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. "YANG for Protocol for Forwarding Policy Configuration (FPC)", Satoru Matsushima, Lyle Bertz, Marco Liebsch, Sri Gundavelli, Danny Moses, Charles Perkins, 2019-04-28, This document provides YANG modules to exhibit a data model for the information models defining 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. Domain Name System Operations (dnsop) ------------------------------------- "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2019-08-23, This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] "Address-specific DNS aliases (ANAME)", Tony Finch, Evan Hunt, Peter van Dijk, Anthony Eden, Willem Mekking, 2019-07-08, This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for address queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner. "DNS Transport over TCP - Operational Requirements", John Kristoff, Duane Wessels, 2019-06-24, This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. It 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, 2019-10-01, 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. "Serving Stale Data to Improve DNS Resiliency", David Lawrence, Warren Kumari, Puneet Sood, 2019-09-18, This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks, and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFC 1034 and RFC 1035 so that data can be kept in the cache beyond the TTL expiry, updates RFC 2181 by interpreting values with the high order bit set as being positive, rather than 0, and suggests a cap of 7 days. "Secret Key Transaction Authentication for DNS (TSIG)", Francis Dupont, Stephen Morris, Paul Vixie, Donald Eastlake, Olafur Gudmundsson, Brian Wellington, 2019-07-07, This document describes a protocol for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates 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, 2019-08-26, Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server 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. Such 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 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. ] "Multi Signer DNSSEC models", Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak, David Blacka, 2019-07-22, 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. This document will present several deployment models that may be suitable. "Message Digest for DNS Zones", Duane Wessels, Piet Barber, Matt Weinberg, Warren Kumari, Wes Hardaker, 2019-09-05, This document describes an experimental protocol and new DNS Resource Record that can be used to provide a message digest over DNS zone data. The ZONEMD Resource Record conveys the message 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 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 includes fields reserved for future work to support large, dynamic zones. "Moving DNSSEC Lookaside Validation (DLV) to Historic Status", Willem Mekking, Dan Mahoney, 2019-10-09, This document obsoletes DNSSEC lookaside validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates, and updates RFC 6840 by excluding the DLV registries from the trust anchor selection. "Terminology for DNS Transports and Location", Paul Hoffman, 2019-08-15, 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, 2019-08-19, 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. "Interoperable Domain Name System (DNS) Server Cookies", Ondrej Sury, Willem Toorop, Donald Eastlake, Mark Andrews, 2019-09-09, 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, 2019-09-23, 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". 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, 2019-07-25, 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 over Multicast DNS at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy respecting discovery service. "Service Registration Protocol for DNS-Based Service Discovery", Stuart Cheshire, Ted Lemon, 2019-07-08, The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2019-09-05, The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Andrew Mortensen, Reddy K, Flemming Andreasen, Nik Teague, Rich Compton, 2019-05-29, 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", Reddy K, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague, 2019-10-18, 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, 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, Reddy K, Wei Pan, 2019-07-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, Reddy K, 2019-08-05, 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 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, Reddy K, Takahiko Nagata, 2019-09-17, 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", Reddy K, Mohamed Boucadair, Jon Shallow, 2019-09-10, 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. DNS PRIVate Exchange (dprive) ----------------------------- "Recommendations for DNS Privacy Service Operators", Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij, Allison Mankin, 2019-10-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, 2019-10-16, This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane, 2019-10-18, This Internet Draft presents a specification for 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, 2019-09-18, This document defines a security protocol providing end to end 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, 2019-10-16, This document describes a revised protocol for the TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol contents, encodings, and convergence layer requirements in Bundle Protocol 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. Several new IANA registries are defined for TCPCLv4 which define some behaviors inherited from TCPCLv3 but with updated encodings and/or semantics. "Bundle-in-Bundle Encapsulation", Scott Burleigh, 2019-08-04, 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. "Minimal TCP Convergence-Layer Protocol", Scott Burleigh, 2019-04-23, This document describes a Minimal TCP (MTCP) "convergence-layer" protocol for the Delay-Tolerant Networking (DTN) Bundle Protocol (BP). MTCP uses Transmission Control Protocol (TCP) to transmit BP "bundles" from one BP node to another node to which it is topologically adjacent in the BP network. The services provided by the MTCP convergence-layer protocol adapter utilize a standard TCP connection for the purposes of bundle transmission. "Asynchronous Management Architecture", Edward Birrane, 2019-08-08, This document describes an asynchronous management architecture (AMA) suitable for providing application-level network management services in a challenged networking environment. Challenged networks are those that require fault protection, configuration, and performance reporting while unable to provide humans-in-the-loop with synchronous feedback or otherwise preserve transport-layer sessions. In such a context, networks must exhibit behavior that is both determinable and autonomous while maintaining compatibility with existing network management protocols and operational concepts. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens, 2019-04-17, RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a Session Initiation Protocol (SIP) session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is all that is needed. Examples of such environments include alerts issued by a temperature sensor, burglar alarm, or chemical spill sensor. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. "A LoST extension to return complete and similar location info", Roger Marshall, Jeff Martin, Brian Rosen, 2019-07-23, This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as a compilation of CAtype xml elements within the existing LoST findServiceResponse message structure. "Validation of Locations Around a Planned Change", Brian Rosen, 2019-04-26, This document defines an extension to LoST (RFC5222) that allows a planned change to the data in the LoST server to occur. Records that previously were valid will become invalid at a date in the future, and new locations will become valid after the date. The extension adds two elements to the request: A URI to be used to inform the LIS that previously valid locations will be invalid after the planned change date, and add a date which requests the server to perform validation as of the date specified. It also adds an optional Time-To-Live element to the response, which informs clients about the current expected lifetime of the validation. This document also provides a conventional XML schema for LoST, as backwards compatible alternative to the RelaxNG schema in RFC5222 EAP Method Update (emu) ----------------------- "Using EAP-TLS with TLS 1.3", John Mattsson, Mohit Sethi, 2019-09-21, 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, 2019-07-08, 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' is also an algorithm update, 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 5G deployments as well. "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", Jari Arkko, Karl Norrman, Vesa Torvinen, 2019-07-25, 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 RFC 5448 (to be superseded by draft-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 all 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, 2019-08-13, 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 memo looks at the this problem in detail and describes the potential solutions available. "EAP Session-Id Derivation", Alan DeKok, 2019-08-29, 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. Since [AKAP] defines the Session-ID for EAP-AKA', the definition for EAP-AKA' is not included here. 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. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2", Alexey Melnikov, Barry Leiba, 2019-07-09, 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-07-01, 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. "IMAP QUOTA Extension", Alexey Melnikov, 2019-06-17, The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. GitHub Integration and Tooling (git) ------------------------------------ "GitHub Configuration for IETF Working Groups", Alissa Cooper, Paul Hoffman, 2019-10-21, The use of GitHub in IETF working group processes is increasing. This document describes possible 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. Discussion of this document takes place on the ietf-and-github mailing list (ietf-and-github@ietf.org), which is archived at . "Using GitHub at the IETF", Martin Thomson, Barbara Stark, 2019-10-10, This document describes best practices for Working Groups that 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 [1]. Source for this draft and an issue tracker can be found at https://github.com/ietf-gitwg/using-github [2]. Global Routing Operations (grow) -------------------------------- "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2019-08-05, 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. "Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Paolo Lucente, Kevin Mi, Shunwan Zhuang, 2019-08-05, The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- In Routing Information Bases (RIBs). This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Out RIBs. It adds a new flag to the peer header to distinguish Adj- RIB-In and Adj-RIB-Out. "Revision to Registration Procedures for Multiple BMP Registries", John Scudder, 2019-06-03, This document updates RFC 7854, BGP Monitoring Protocol (BMP) by making a change to the registration procedures for several registries. Specifically, any BMP registry with a range of 32768-65530 designated "Specification Required" has that range re- designated as "First Come First Served". "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Alexander Azimov, 2019-07-26, 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. "BMP Peer Up Message Namespace", John Scudder, 2019-07-24, RFC 7854, BMP, uses different message types for different purposes. Most of these are Type, Length, Value (TLV) structured. One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Subsequent experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol. This document updates RFC 7854 by creating an independent namespace for the Peer Up message. The changes in this document are formal only, compliant implementations of RFC 7854 also comply with this specification. "TLV support for BMP Route Monitoring and Peer Down Messages", Paolo Lucente, Yunan Gu, Henk Smit, 2019-10-15, Most of the message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data; however Route Monitoring message (to provide a snapshot of the monitored Routing Information Base) and Peer Down message (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 this document does not want 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, 2018-03-05, 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 for all NAT traversal procedures. "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, Miika Komu, 2019-10-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. 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, Ray Hunter, Chris Griffiths, 2019-05-10, Designation of services and devices of a home network is not user friendly, and mechanisms should enable a user to designate services and devices inside a home network using names. In order to enable internal communications while the home network experiments Internet connectivity shortage, the naming service should be hosted on a device inside the home network. On the other hand, home networks devices have not been designed to handle heavy loads. As a result, hosting the naming service on such home network device, visible on the Internet exposes this device to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. As result, home networks may prefer not serving the naming service for the Internet, but instead prefer outsourcing it to a third party. This document describes a mechanisms that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure. "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", Niels ten Oever, Gurshabad Grover, 2019-06-07, 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]. "Notes on networking standards and politics", Niels ten Oever, 2019-09-28, The IETF cannot ordain what standards or protocols are to be used on networks, but the standards development process in the IETF does have an impact on society through its normative standards setting process. This document aims to bring about a better understanding on the political nature of standards and protocols. Among other things, the IETF's work affects what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards reflect what is considered by the technical community to be feasible and good practice. Whereas there might not be agreement among the Internet protocol community on the specific political nature of the technological development process and its outputs, it is generally agreed that standards and protocols are both products of a political process, and they can also be used for political means. "Freedom of Association on the Internet", Stephane Couture, Joseph Hall, Niels ten Oever, Gisela de Acha, 2019-08-22, This document establishes the link 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. Hypertext Transfer Protocol (httpbis) ------------------------------------- "Cookies: HTTP State Management Mechanism", Adam Barth, Mike West, 2019-04-27, 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 Headers for HTTP", Mark Nottingham, Poul-Henning Kamp, 2019-08-25, 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 fields. It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. "Expect-CT Extension for HTTP", estark@google.com, 2018-12-09, This document defines a new HTTP header field named Expect-CT, which allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency deployments. Further, web host operaters can use Expect-CT to ensure that, if a UA which supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. "HTTP Random Access and Live Content", Craig Pratt, Darshak Thakore, Barbara Stark, 2019-03-07, To accommodate byte range requests for content that has data appended over time, this document defines semantics that allow a HTTP client and server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and ends at an indeterminate offset. "Secondary Certificate Authentication in HTTP/2", Mike Bishop, Nick Sullivan, Martin Thomson, 2019-04-25, 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, 2019-07-08, 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, 2019-07-08, 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, 2019-07-08, 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 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, and portions of RFC 7230. "The Proxy-Status HTTP Header Field", Mark Nottingham, Piotr Sikora, 2019-05-06, This document defines the Proxy-Status HTTP header field to convey the details of errors generated by HTTP intermediaries. Note to Readers _RFC EDITOR: please remove this section before publication_ Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/proxy-status [3]. "Using TLS 1.3 with HTTP/2", David Benjamin, 2019-10-17, This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction. "Resource Digests for HTTP", Roberto Polli, Lucas Pardue, 2019-07-04, 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. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, Henk Birkholz, 2019-07-05, This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. "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, Eunsoo Kim, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2019-07-24, 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, 2019-07-25, 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, 2019-07-24, 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, 2019-07-24, This document describes 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 malicious activity, anomalous behavior, and 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. 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, 2019-10-15, 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 Harmful Consequences of the Robustness Principle", Martin Thomson, 2019-05-06, Jon Postel's famous statement of "Be liberal in what you accept, and conservative in what you send" is a principle that has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time. For a protocol that is actively maintained, the robustness principle can, and should, be avoided. "Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries", Russ Housley, Olaf Kolkman, 2019-06-26, This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries. "Fifty Years of RFCs", Heather Flanagan, 2019-08-09, This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540. "Long-term Viability of Protocol Extension Mechanisms", Martin Thomson, 2019-08-07, The ability to change protocols depends on exercising the extension and version negotiation mechanisms that support change. Protocols that don't use these mechanisms can find that deploying changes can be difficult and costly. "The Internet is for End Users", Mark Nottingham, 2019-08-26, This document explains why the IAB believes the IETF should consider end-users as its highest priority concern, and how that can be done. "Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)", Martin Thomson, Mark Nottingham, 2019-09-18, The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration. IETF Administrative Support Activity 2 (iasa2) ---------------------------------------------- "Update to the Process for Selection of Trustees for the IETF Trust", Jari Arkko, Ted Hardie, 2019-02-04, This memo updates the process for selection of trustees for the IETF Trust. Previously, the Internet Administrative Oversight Committee (IAOC) members also acted as trustees, but the IAOC has been eliminated as part of an update of the structure of the Internet Administrative Support Activity (IASA). This memo specifies that the trustees shall be selected separately. This memo obsoletes RFC 4371. The changes relate only to the selection of trustees. All other aspects of the IETF Trust remain as they are today. "Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust", Jari Arkko, 2018-10-11, This document is published to capture the rationale for the changes introduced in RFC NNNN (RFC Editor: please replace NNNN with the RFC number of [I-D.ietf-iasa2-trust-update]), Update to the Process for Selection of Trustees for the IETF Trust. At the time RFC NNNN was published, IETF administrative structure changes ("IASA 2.0") had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents", Joel Halpern, 2019-08-21, Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IAOC which was part of IASA. "Update to the IETF Anti-Harassment Procedures for the Replacement of the IAOC with the IETF Administration LLC", Pete Resnick, Adrian Farrel, 2019-09-14, The IETF Anti-Harassment Procedures are described in RFC 7776. The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms. RFC 7776 contained updates to RFC 7437. draft-ietf-iasa2-rfc7437bis has incorporated those updates, so this document also updates RFC 7776 to remove those updates. NOTE for RFC Editor and Readers of this Document When published as an RFC o All references to and mentions of draft-ietf-iasa2-rfc7437bis in this document should be replaced by the RFC that results from draft-ietf-iasa2-rfc7437bis. o The string "XXXX" should be replaced with the RFC number assigned to the RFC that results from draft-ietf-iasa2-rfc7437bis. o This note should be removed. *** END OF NOTE *** "IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", Murray Kucherawy, Robert Hinden, Jason Livingood, 2019-07-11, The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF LLC are selected, confirmed, and recalled is specified in this document. This document is based on RFC7437. Only those updates required to reflect the changes introduced by IASA 2.0 have been included. Any other changes will be addressed in future documents. This document obsoletes RFC7437 and RFC8318. "Consolidated IASA 2.0 Updates of IETF Administrative Terminology", John Klensin, 2019-03-11, In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes. "The IETF-ISOC Relationship", Gonzalo Camarillo, Jason Livingood, 2019-08-27, This document summarises the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031. "Structure of the IETF Administrative Support Activity, Version 2.0", Brian Haberman, Joseph Hall, Jason Livingood, 2019-04-12, The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this document is to document and describe the IETF Administrative Support Activity, version 2 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board, the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF Administration LLC Board. This document obsoletes RFC 4071, RFC 4333, and RFC 7691. 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, 2019-10-13, 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 proposes a way to avoid premature failure. This document updates RFC 8445 and RFC XXXX. [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, 2019-06-02, 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, 2019-10-02, 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). "Design Considerations for Applying ICN to IoT", Ravi Ravindran, Yanyong Zhang, Luigi Grieco, Anders Lindgren, Jeff Burke, Bengt Ahlgren, Aytac Azgin, 2019-05-02, The Internet of Things (IoT) promises to connect billions of objects to the Internet. After deploying many stand-alone IoT systems in different domains, the current trend is to develop a common, "thin waist" of protocols to enable a horizontally unified IoT architecture. The objective of such an architecture is to make resource objects securely accessible to applications across organizations and domains. Towards this goal, quite a few proposals have been made to build an application-layer based unified IoT platform on top of today's host-centric Internet. However, there is a fundamental mismatch between the host-centric nature of today's Internet and the mostly information-centric nature of the IoT domain. To address this mismatch, the common set of protocols and network services offered by an information-centric networking (ICN) architecture can be leveraged to realize an ICN-based IoT (or ICN- IoT) architecture that can take advantage of the salient features of ICN such as naming, security, mobility, compute and efficient content and service delivery support offered by it. In this draft, we summarize the general IoT demands, and ICN features that support these requirements, and then discuss the challenges to realize an ICN-based IoT framework. Beyond this, the goal of this draft is not to offer any specific ICN-IoT architectural proposal. "Native Deployment of ICN in LTE, 4G Mobile Networks", Prakash suthar, Milan Stolic, Anil Jangam, Dirk Trossen, Ravi Ravindran, 2019-09-09, 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 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 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 majority of the work is focused on fixed networks. The main focus of this draft is on native deployment of ICN in cellular mobile networks by using ICN in 3GPP protocol stack. ICN has an inherent capability for multicast, anchorless mobility, 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 of PDCP/RLC/MAC/PHY or in a dual stack mode (along with IP) help optimize the mobile networks by leveraging the inherent benefits of ICN. "Deployment Considerations for Information-Centric Networking (ICN)", Akbar Rahman, Dirk Trossen, Dirk Kutscher, Ravi Ravindran, 2019-09-03, Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described including the key overlay and underlay approaches. Then proposed deployment migration paths are outlined to address major practical issues such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-Centric Networking Research Group (ICNRG). "MAP-Me : Managing Anchorless Mobility in Content Centric Networking", Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini, 2019-04-25, Consumer mobility is supported in ICN by design, in virtue of its connectionless pull-based communication model; producer mobility though is not natively supported. This document describes MAP-Me, an anchor-less solution to manage micro-mobility of content producers in the CCN (Content Centric Networking) and NDN (Named Data Networking) architectures, with support for latency-sensitive applications. MAP- Me consists in the combination of two data plane protocols, triggered by producer movements, and leveraging ICN named-based data plane. The main protocol consists in a lightweight FIB update process, complemented by a mechanism of local notification and scoped discovery suitable for low latency applications and fast mobility. "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Hitoshi Asaeda, Atsushi Ooka, Xun Shao, 2019-07-08, 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 content forwarder and consumer, and 3) the states of in-network cache per name prefix. "Design Guidelines for Name Resolution Service in ICN", Jungha Hong, Taewan You, Yong-Geun Hong, Lijun Dong, Cedric Westphal, Borje Ohlman, 2019-07-08, This document discusses the motivation and design guidelines for Name Resolution Service (NRS) in ICN. The NRS in ICN is to translate an object name into some other information such as a locator and another name which is used for forwarding the object request. "Architectural Considerations of ICN using Name Resolution Service", Jungha Hong, Taewan You, Yong-Geun Hong, Ved Kafle, Bastiaan Wissingh, 2019-07-08, 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 ICN. "ICN Adaptation to LowPAN Networks (ICN LoWPAN)", Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin, 2019-09-19, 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. "Internet Protocol Tunneling over Content Centric Mobile Networks", Greg White, Susmit Shannigrahi, Chengyu Fan, 2019-08-02, This document describes a protocol that enables tunneling of Internet Protocol traffic over a Content Centric Network (CCN) 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 CCN 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 CCN/NDN for this purpose paves the way for the deployment of ICN native applications on the mobile network. "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Ravi Ravindran, Prakash suthar, Dirk Trossen, Chonggang Wang, Greg White, 2019-10-07, The proposed 3GPP's 5G core nextgen architecture (5GC) offers flexibility to introduce new user and control plane function, considering the support for network slicing functions, that allows 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. Inter-Domain Routing (idr) -------------------------- "BGP Bestpath Selection Criteria Enhancement", Rajiv Asati, 2019-06-05, BGP specification (RFC4271) prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and would desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. "Extended Optional Parameters Length for BGP OPEN Message", Enke Chen, John Scudder, 2019-08-01, The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we update RFC 4271 by extending the BGP OPEN length field in a backward-compatible manner. The Parameter Length field of individual Optional Parameters is also extended. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Kevin Wang, 2019-07-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. "Extended Message support for BGP", Randy Bush, Keyur Patel, David Ward, 2019-08-16, The BGP specification mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support newer AFI/SAFIs and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification RFC4271 by extending the maximum message size from 4,096 octets to 65,535 octets for all except the OPEN and KEEPALIVE messages. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra, 2019-08-09, 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, 2019-10-14, 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. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2019-10-01, There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs. "Performance-based BGP Routing Mechanism", Xiaohu Xu, Shraddha Hegde, Ketan Talaulikar, Mohamed Boucadair, Christian Jacquenet, 2019-10-13, The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. "BGP Dissemination of L2VPN Flow Specification Rules", Hao Weiguo, Donald Eastlake, Jim Uttaro, Stephane Litkowski, Shunwan Zhuang, 2019-07-08, This document defines a BGP flow-spec extension to disseminate L2 VPN Ethernet traffic filtering rules. SAFI=134 in draft-ietf-idr- rfc5575bis is redefined for this purpose. A new subset of component types and extended community also are defined. A new subset of component types and new extended community also are defined. "Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang, Qin WU, Jeff Tantsura, 2019-10-18, As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE. "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Keyur Patel, Saikat Ray, Jie Dong, 2019-05-16, Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to BGP Link-State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Christoph Dietzel, 2019-09-02, When BGP route servers are used, the data plane is not congruent with the control plane. Therefore, peers at an Internet exchange can lose data connectivity without the control plane being aware of it, and packets are lost. This document proposes the use of a newly defined BGP Subsequent Address Family Identifier (SAFI) both to allow the route server to request its clients use BFD to track data plane connectivity to their peers' addresses, and for the clients to signal that connectivity state back to the route server. "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas, 2019-10-04, 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-09-30, 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. "Segment Routing Prefix SID extensions for BGP", Stefano Previdi, Clarence Filsfils, Acee Lindem, Arjun Sreekantiah, Hannes Gredler, 2018-06-26, Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An SR domain is defined as a single administrative domain for global SID assignment. This document defines an optional, transitive BGP attribute for announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) information and the specification for SR-MPLS SIDs. "BGP Dissemination of Network Virtualization Overlays (NVO3) Flow Specification Rules", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2019-07-08, This draft specifies a new subset of component types to support the (Network Virtualization Overlays (NVO3)) flow-spec application. "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2019-08-19, This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. "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, 2019-06-18, 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 specifies IPv4 traffic Flow Specifications via a BGP NLRI which carries traffic Flow Specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document obsoletes RFC5575 and RFC7674 to correct unclear specifications in the flow filters. Applications which use the bgp Flow Specification are: 1) application which automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of- service attacks; 2) applications which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the extended community Flow Specification actions. "BGP Next-Hop dependent capabilities", Bruno Decraene, Kireeti Kompella, Wim Henderickx, 2019-06-11, RFC 5492 advertises the capabilities of the BGP peer. When the BGP peer is not the same as the BGP Next-Hop, it is useful to also be able to advertise the capability of the BGP Next-Hop, in particular to advertise forwarding plane features. This document defines a mechanism to advertise such BGP Next Hop dependent Capabilities. This document defines a new BGP non-transitive attribute to carry Next-Hop Capabilities. This attribute is guaranteed to be deleted or updated when the BGP Next Hop is changed, in order to reflect the capabilities of the new BGP Next-Hop. This document also defines a Next-Hop capability to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard to this BGP signaling. "Route Leak Prevention using Roles in Update and Open messages", Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Kotikalapudi Sriram, 2019-07-08, 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, Gregory Mirsky, Nikos Triantafillis, 2019-10-15, 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. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Paul Mattes, Eric Rosen, Dhanendra Jain, Steven Lin, 2019-07-06, This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined. "Signalling ERLD using BGP-LS", Gunter Van de Velde, Wim Henderickx, Matthew Bocci, Keyur Patel, 2019-08-20, This document defines the attribute encoding to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node to a centralised controller (PCE/SDN). "Extended BGP Administrative Shutdown Communication", Job Snijders, Jakob Heitz, John Scudder, Alexander Azimov, 2019-10-16, 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, Shaowen Ma, 2019-09-29, 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, 2019-10-15, 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" and "Reserved". "BGP Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Bruno Decraene, 2019-07-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 functions and other attributes via BGP. "Application Specific Attributes Advertisement with BGP Link-State", Ketan Talaulikar, Peter Psenak, Jeff Tantsura, 2019-06-02, 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, 2019-07-08, 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, Gregory Mirsky, 2019-06-02, 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, 2019-09-03, BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET in Border Gateway Protocol (BGP). This document updates RFC 4271 and 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. "Support for Long-lived BGP Graceful Restart", Jim Uttaro, Enke Chen, Bruno Decraene, John Scudder, 2019-09-05, In this document we introduce a new BGP capability termed "Long-lived Graceful Restart Capability" so that stale routes can be retained for a longer time upon session failure. A well-known BGP community "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community, "NO_LLGR", is introduced to mark routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least-preferred, and their advertisements be limited to BGP speakers that have advertised the new capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is. We update RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between PE and CE. "Distribution of Link-State and Traffic Engineering Information Using BGP", Ketan Talaulikar, 2019-09-14, 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, 2019-09-21, 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. Internet Area (int) ------------------- "Guidelines and Registration Procedures for Interface Types and Tunnel Types", Dave Thaler, Dan Romascanu, 2019-10-03, The registration and use of interface types ("ifType" values) predated the use of IANA Considerations sections and YANG modules, and so confusion has arisen about the interface type allocation process. Tunnel types were then added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863, and provides updated guidelines for the definition of new interface types and tunnel types, for consideration by those who are defining, registering, or evaluating those definitions. Internet Area Working Group (intarea) ------------------------------------- "IP Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley, 2019-09-12, This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459. "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2019-10-04, 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, 2019-10-08, 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, 2019-09-11, 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, 2019-09-11, 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 Chang, daniel.bernier@bell.ca, John Lemon, 2019-09-11, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be embedded into a variety of transports such as NSH, Segment Routing, Geneve, native IPv6 (via extension header), or IPv4. In-situ OAM can be used to complement OAM mechanisms based on e.g. ICMP or other types of probe packets. "Simple Two-way Active Measurement Protocol", Gregory Mirsky, Guo Jun, Henrik Nydell, Richard Foote, 2019-10-18, This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Gregory Mirsky, Min Xiao, Wei Luo, 2019-09-02, This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. "Advanced Unidirectional Route Assessment (AURA)", Jose Alvarez-Hamelin, Alfred Morton, Joachim Fabini, Carlos Pignataro, Ruediger Geib, 2019-09-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, 2019-07-01, The Alternate Marking method, as presented in RFC 8321 [RFC8321], 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 aims to generalize and expand 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. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema. "Simple Two-way Active Measurement Protocol Optional Extensions", Gregory Mirsky, Min Xiao, Guo Jun, Henrik Nydell, Richard Foote, Adi Masputra, 2019-09-20, 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. "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, 2019-09-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 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, 2019-10-12, In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document presents new flags in the IOAM Trace Option headers. Specifically, the document defines the Loopback and Active flags. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Postquantum Preshared Keys for IKEv2", Scott Fluhrer, David McGrew, Panos Kampanakis, Valery Smyslov, 2019-03-28, The possibility of Quantum Computers pose a serious challenge to cryptography 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. "Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)", Daniel Migault, Tobias Guggemos, Yoav Nir, 2019-10-21, Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. "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. "Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana Prasad, 2019-07-08, This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. "Intermediate Exchange in the IKEv2 Protocol", Valery Smyslov, 2019-07-24, 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 Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic Service Set", Nabil Benamar, Jerome Haerri, Jong-Hyouk Lee, Thierry Ernst, Thierry Ernst, 2019-08-09, This document provides methods and settings, for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios is not covered in this specification and is subject of future work. "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Jaehoon Jeong, 2019-10-03, This document discusses the problem statement and use cases of IP- 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 IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document specifies requirements in IP-based vehicular networking, and suggests the direction of solutions satisfying those requirements. IS-IS for IP Internets (isis) ----------------------------- "Advertising L2 Bundle Member Link Attributes in IS-IS", Les Ginsberg, Ahmed Bashandy, Clarence Filsfils, Mohan Nanduri, Ebben Aries, 2017-05-25, There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS 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 IS-IS to advertise the link attributes of layer 2 (L2) bundle members. JSON Mail Access Protocol (jmap) -------------------------------- "Handling Message Disposition Notification with JMAP", Raphael Ouazana, 2019-07-22, 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, 2019-07-23, 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, 2019-04-29, This document specifies a data model for synchronising calendar data with a server using JMAP. "Extensions to JMAP for S/MIME signature verification", Alexey Melnikov, 2019-07-08, This document specifies extension to JMAP for returning S/MIME signature verification status. "JMAP for Quotas", Rene Cordier, Michael Bailly, 2019-09-30, This document specifies a data model for handling quotas on mailboxes with a server using JMAP. 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, 2018-08-21, 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. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs", Panos Kampanakis, Quynh Dang, 2019-07-22, Digital signatures are used to sign messages, X.509 certificates and CRLs. This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile" (RFC3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. "Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)", Panos Kampanakis, Quynh Dang, 2019-09-17, This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. "DNS Certification Authority Authorization (CAA) Resource Record", Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews, 2019-05-30, The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. This document obsoletes RFC 6844. "Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, 2019-09-18, This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. "Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)", Russ Housley, 2019-08-23, The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. "Problem Statement and Requirements for Header Protection", Alexey Melnikov, Bernie Hoeneisen, 2019-07-08, Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issue has been expressed in the IETF LAMPS Working Group only recently. The existing S/MIME specification is likely to be updated regarding header protection. Several LAMPS WG participants expressed the opinion that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME. This document describes the problem statement, generic use cases, and requirements. Additionally it drafts possible solutions to address the challenge. Finally some best practices are collected. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2019-07-23, 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, 2019-09-07, 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, 2019-06-16, 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, 2019-06-16, This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new 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, 2019-10-07, 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, 2019-09-03, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "LISP Virtual Private Networks (VPNs)", Victor Moreno, Dino Farinacci, 2019-05-16, This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. "LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc Portoles-Comeras, Vrushali Ashtaputre, Victor Moreno, Fabio Maino, Dino Farinacci, 2019-05-16, 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, 2019-05-15, 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, 2019-10-07, 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, 2019-09-30, This document describes a new LISP Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. "LISP Generic Protocol Extension", Fabio Maino, Jennifer Lemon, Puneet Agarwal, Darrel Lewis, Michael Smith, 2019-10-18, 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, 2019-09-11, 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, 2019-08-16, 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, 2019-09-16, 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. IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "LPWAN Static Context Header Compression (SCHC) for CoAP", Ana Minaburo, Laurent Toutain, Ricardo Andreasen, 2019-10-09, This draft defines the way SCHC header compression can be applied to CoAP headers. The CoAP header structure differs from IPv6 and UDP protocols 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 document explains how to use the SCHC compression mechanism for CoAP. "Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6", Ana Minaburo, Laurent Toutain, Carles Gomez, Dominique Barthel, Juan Zuniga, 2019-07-23, This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has been designed for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in both the LPWAN device and the network side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the layer-2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. "Static Context Header Compression (SCHC) over LoRaWAN", Olivier Gimenez, Ivaylo Petrov, Julien Catalano, 2019-10-09, 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, 2019-04-23, This document describes a YANG data model for the SCHC (Static Context Header Compression). A generic module is defined, that can be applied for any headers and also a specific model for the IPv6 UDP protocol stack is also proposed. Note that this draft is a first attempt to define a YANG data module for SCHC, more work is needed to use all the YANG facilities. "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Laurent Toutain, 2019-04-26, The Static Context Header Compression (SCHC) specification describes a header compression scheme and a fragmentation 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. "SCHC over NB-IoT", Edgar Ramos, Ana Minaburo, 2019-05-06, 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) ------------------------ "IS-IS Extensions for Segment Routing", Stefano Previdi, Les Ginsberg, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Bruno Decraene, 2019-05-19, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. "OSPFv3 Extensions for Segment Routing", Peter Psenak, Stefano Previdi, 2019-01-09, Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. "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-stack Depth Using OSPF", Xiaohu Xu, Sriganesh Kini, Peter Psenak, Clarence Filsfils, Stephane Litkowski, Matthew Bocci, 2019-10-21, 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 tunnel unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability of 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 OSPF and OSPFv3. These mechanism is particularly useful in the environment where Segment Routing (SR) is used, where label advertisements are done via protocols like OSPF 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, 2019-10-21, 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 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. These mechanisms are particularly useful, where label advertisements are done via protocols like IS-IS. "Host Router Support for OSPFv2", Keyur Patel, Padma Pillay-Esnault, Manish Bhardwaj, Serpil Bayraktar, 2019-09-13, The Open Shortest Path First Version 2 (OSPFv2) does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document assigns a new bit (Host-bit) in the OSPF Router-LSA bit registry and in the OSPF Router Informational Capability Bits Registry that enables a host router to advertise that it is a non-transit router. It also describes the changes needed to support the Host-bit in the domain. In addition, this document updates OSPF Stub Router Advertisement (RFC6987) to advertise for type-2 External and NSSA LSAs with a high cost in order to repel traffic effectively. "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2019-08-13, 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, 2019-07-07, This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing. "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels", Anton Smirnov, Alvaro Retana, Michael Barnes, 2019-08-16, When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. "IS-IS TE Attributes per application", Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx, John Drake, 2019-10-17, 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., SRTE, LFA) 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 draft introduces new link attribute advertisements which address both of these shortcomings. It also discusses backwards compatibility issues and how to minimize duplicate advertisements in the presence of routers which do not support the extensions defined in this document. "OSPF Link Traffic Engineering Attribute Reuse", Peter Psenak, Les Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake, 2019-09-19, Various link attributes have been defined in OSPF in the context of the MPLS Traffic Engineering (TE) and GMPLS. Many of these link attributes can be used for applications other than MPLS TE or GMPLS. This document defines how to distribute such attributes in OSPFv2 and OSPFv3 for applications other than MPLS TE or GMPLS. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2019-09-18, 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. "Restart Signaling for IS-IS", Les Ginsberg, Paul Wells, 2019-09-19, This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306. "IGP extension for PCEP security capability support in the PCE discovery", Diego Lopez, Qin WU, Dhruv Dhody, Zitao Wang, Daniel King, 2019-09-03, When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCEP security (e.g., Transport Layer Security(TLS), TCP Authentication Option (TCP-AO)) support capability. This document proposes new capability flag bits for PCE-CAP-FLAGS sub-TLV that can be announced as attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFC 5088 and RFC 5089 to allow advertisement of Key ID or Key Chain Name Sub-TLV to support TCP AO security capability. "IS-IS Routing for Spine-Leaf Topology", Naiming Shen, Les Ginsberg, Sanjay Thyamagundalu, 2019-09-02, This document describes a mechanism for routers and switches in a Spine-Leaf type topology to have non-reciprocal Intermediate System to Intermediate System (IS-IS) routing relationships between the leafs and spines. The leaf nodes do not need to have the topology information of other nodes and exact prefixes in the network. This extension also has application in the Internet of Things (IoT). "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Les Ginsberg, Huaimo Chen, Tony Przygienda, Dave Cooper, Luay Jalil, Srinath Dontula, 2019-06-04, 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-09-12, 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, 2019-10-04, 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, 2019-07-22, 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. Link State Vector Routing (lsvr) -------------------------------- "Shortest Path Routing Extensions for BGP Protocol", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2019-09-30, Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have lead 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, 2019-05-01, 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, 2019-07-07, 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 logical link IP encapsulation abilities, IP neighbor address discovery, 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-06-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. "Alternative Elliptic Curve Representations", Rene Struik, 2019-07-24, 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. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP Latency Range Extension", Bow-Nan Cheng, Lou Berger, 2018-10-17, This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. "DLEP Link Identifier Extension", Rick Taylor, Stan Ratliff, 2019-09-10, The Dynamic Link Exchange Protocol, RFC 8175, describes a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination. This document describes a DLEP Extension allowing modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. MBONE Deployment (mboned) ------------------------- "Multicast in the Data Center Overview", Mike McBride, Olufemi Komolafe, 2019-07-23, 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 judiously 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-09-26, Well-known issues with multicast have prevented the deployment of multicast in 802.11 and other local-area wireless environments. This document offers guidance on known limitations and problems with wireless 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, 2019-09-12, This document intents to provide a general and all-round multicast YANG data model, which tries to stand at a high level to take full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. And also, there will define several possible RPCs about how to interact between multicast YANG data model and multicast protocol models. This multicast YANG data model is mainly used by the management tools run by the network operators in order to manage, monitor and debug the network resources used to deliver multicast service, as well as gathering some data from the network. "Deprecating ASM for Interdomain Multicast", Mikael Abrahamsson, Tim Chown, Leonard Giuliano, Toerless Eckert, 2019-09-04, 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 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. Requirements Language and Terminology "DNS Reverse IP AMT Discovery", Jake Holland, 2019-06-14, This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource record named AMTRELAY when discovering AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "JSON binding of IODEF", Takeshi Takahashi, Roman Danyliw, Mio Suzuki, 2019-07-23, 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. "Definition of ROLIE CSIRT Extension", Stephen Banghart, John Field, 2019-09-06, This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type categories and related requirements needed to support Computer Security Incident Response Team (CSIRT) use cases. The indicator and incident information types are defined as ROLIE extensions. Additional supporting requirements are also defined that describe the use of specific formats and link relations pertaining to the new information types. "Definition of the ROLIE Vulnerability Extension", Stephen Banghart, 2019-09-06, This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type categories and related requirements needed to support Vulnerability use cases. Additional categories, properties, and requirements based on content type enables a higher level of interoperability between ROLIE implementations, and richer metadata for ROLIE consumers. In particular, usage of the Common Vulnerability Enumeration (CVE) [cve] format is discussed. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert, 2019-07-08, 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, 2019-09-13, This document describes the architecture and 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. "The Messaging Layer Security (MLS) Federation", Emad Omara, Raphael Robert, 2019-09-11, This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations can interoperate by defining the message format for user key retrieval. The document also describes some use cases where federation could be useful. 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", Keith Drage, Maridi Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, Jose Recio, 2019-08-27, This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework. Two network configurations are documented: a WebRTC end- to-end configuration (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, 2019-10-17, 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. Multiprotocol Label Switching (mpls) ------------------------------------ "Entropy label for SPRING tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir, Jeff Tantsura, 2018-07-16, Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing MPLS. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Gregory Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2019-08-21, 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-06-08, 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. "Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula, Uwe Joorde, Arvind Venkateswaran, 2019-07-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing multicast LDP point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB module defined in this document is extension of LDP MIB defined in RFC3815 which supports only for LDP point-to-point LSPs. "A YANG Data Model for MPLS Base", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, 2019-09-12, 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 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, 2019-09-12, 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 mLDP", Kamran Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura, Sowmya Krishnaswamy, 2019-05-31, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP data model augments the LDP data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). "YANG Data Model for MPLS LDP", Kamran Raza, Rajiv Asati, Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, 2019-05-30, 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, Gregory Mirsky, Giuseppe Fioccola, 2019-07-29, 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, Gregory 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, 2019-07-04, This document defines Resource Reservation Protocol (RSVP) Traffic- Engineering (TE) signaling extensions that reduce the amount of RSVP signaling required for Fast Reroute (FRR) procedures and subsequently improve the scalability of the RSVP-TE signaling when undergoing FRR convergence after a link or node failure. Such extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) 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. "MPLS Egress Protection Framework", Yimin Shen, Jeyananth Jeganathan, Bruno Decraene, Hannes Gredler, Carsten Michel, Huaimo Chen, 2019-07-31, This document specifies a fast reroute framework for protecting IP/ MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of point of local repair (PLR), protector, and backup egress router, and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR, and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control plane protocols converge on the topology changes due to the egress failure. "SR-MPLS over IP", Xiaohu Xu, Stewart Bryant, Adrian Farrel, Syed Hassan, Wim Henderickx, Zhenbin Li, 2019-06-16, MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS can be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. "LDP Extensions for RMR", Santosh Esale, Kireeti Kompella, 2019-06-11, 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. "RFC8287 Sub-TLV Length Clarification", Nagendra Kumar, Carlos Pignataro, Faisal Iqbal, Sasha Vainshtein, 2019-08-08, 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. RFC8287 proposes 3 Target FEC Stack Sub-TLVs. While the standard defines the format and procedure to handle those Sub-TLVs, it does not sufficiently clarify how the length of the Segment ID Sub-TLVs should be computed to include in the Length field of the Sub-TLVs which may result in interoperability issues. This document updates RFC8287 by clarifying the length of each Segment ID Sub-TLVs defined in RFC8287. "Special Purpose Label terminology", Loa Andersson, Kireeti Kompella, Adrian Farrel, 2019-07-07, This document discusses and recommends a terminology that may be used when MPLS Special Purpose Labels (SPL) are specified and documented. Note: The rest of the text in this section is not really part of the abstract even though the text is placed here. It is working notes. Note: At least at the moment it is not the intention to take this document to an RFC, but it might be polled to become a wg document to see if the MPLS working group agree on the proposed terminology. Note: The changes we propose are minor, but we might have to progress the document to RFC since there is a proposed change to the "Special- Purpose Multiprotocol Label Switching (MPLS) Label Values" registry. "Resilient MPLS Rings and Multicast", Zhaohui Zhang, Santosh Esale, 2019-08-13, With Resilient MPLS Rings (RMR), although all existing multicast procedures and solutions can work as is, there are optimizations that could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting for both mLDP and RSVP-TE P2MP tunnels. This document describes RMR multicast on a high level, with detailed protocol procedure for RSVP- TE P2MP optimizations specified in a separate document. This document also discusses end to end multicast when there are RMRs. "Updating the IANA MPLS LSP Ping Parameters", Loa Andersson, Tarek Saad, Mach Chen, Carlos Pignataro, 2019-10-17, This document updates RFC 8029 and RFC 8611 that define IANA registries for MPLS LSP Ping. The updates are mostly for clarification and to align this registry with recent developments.. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch, 2019-06-08, TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. Meeting Venue (mtgvenue) ------------------------ "IETF Plenary Meeting Venue Selection Process", Eliot Lear, 2018-06-14, The IASA has responsibility for arranging IETF plenary meeting Venue selection and operation. This memo specifies IETF community requirements for meeting venues, including hotels and meeting room space. It directs the IASA to make available additional process documents that describe the current meeting selection process. "High level guidance for the meeting policy of the IETF", Suresh Krishnan, 2018-07-02, This document describes a meeting location policy for the IETF and the various stakeholders for realizing such a policy. Network Configuration (netconf) ------------------------------- "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu, Liang Xia, 2019-10-18, 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. "RESTCONF Client and Server Models", Kent Watsen, 2019-10-18, This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many 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. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-10-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, Gary Wu, Liang Xia, 2019-10-18, 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. "NETCONF Client and Server Models", Kent Watsen, 2019-10-18, This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many 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. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-10-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log "Dynamic subscription to YANG Events and Datastores over RESTCONF", Eric Voit, Reshad Rahman, Einar Nilsen-Nygaard, Alexander Clemm, Andy Bierman, 2019-06-12, This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. "A YANG Data Model for a Keystore", Kent Watsen, 2019-10-18, 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. "Notification Message Headers and Bundles", Eric Voit, Henk Birkholz, Andy Bierman, Alexander Clemm, Tim Jenkins, 2019-08-15, This document defines a new notification message format. Included are: o a new notification mechanism and encoding to replace the one way operation of RFC-5277 o a set of common, transport agnostic message header objects. o how to bundle multiple event records into a single notification message. o how to ensure these new capabilities are only used with capable receivers. "Common YANG Data Types for Cryptography", Kent Watsen, HAIGUANG Wang, 2019-10-18, This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. "A YANG Data Model for a Truststore", Kent Watsen, 2019-10-18, This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates and SSH host-keys that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, the X.509 certificates may have multiple uses, including authenticating protocol peers and verifying signatures. Editorial Note (To be removed by RFC Editor) This draft contains many 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 "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for draft-ietf-netconf-crypto- types Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-10-18" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log "Yang-Push Notification Capabilities", Balazs Lengyel, Alexander Clemm, Benoit Claise, 2019-09-05, This document proposes a YANG module that allows a server to specify server capabilities related to "Subscription to YANG Datastores" (Yang-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation time, but also allow it to be reported at run-time. "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael Scharf, 2019-10-18, 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. "An HTTPS-based Transport for Configured Subscriptions", Mahesh Jethanandani, Kent Watsen, 2019-09-17, This document defines a YANG data module for configuring HTTPS based configured subscription, as defined I-D.ietf-netconf-subscribed- notifications. The use of HTTPS maximizes transport-level interoperability, while allowing for encoding selection from text, e.g. XML or JSON, to binary. 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-07-15, This document describes YANG mechanisms for defining abstract data structures with YANG. "YANG Module Tags", Christian Hopps, Lou Berger, Dean Bogdanovic, 2019-09-25, 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. "Comparison of NMDA datastores", Alexander Clemm, Yingzhen Qu, Jeff Tantsura, Andy Bierman, 2019-07-08, This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. "Handling Long Lines in Inclusions in Internet-Drafts and RFCs", Kent Watsen, Adrian Farrel, Qin WU, 2019-09-05, 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 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, 2019-08-12, There is a need to document data defined in YANG models when a live server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a operation/request) and decorates it with metadata. "YANG Module Versioning Requirements", Joe Clarke, 2019-07-03, This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. "Common YANG Data Types", Juergen Schoenwaelder, 2019-07-21, This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6991. "YANG Geo Location", Christian Hopps, 2019-04-29, 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. "Factory Default Setting", Qin WU, Balazs Lengyel, Ye Niu, 2019-09-10, This document defines a method to reset a server to its factory- default content. The reset operation may be used e.g. during initial zero-touch configuration or when the existing configuration has major errors, so re-starting the configuration process from scratch is the best option. A new factory-reset RPC is defined. Several methods of documenting the factory-default content are specified. Optionally a new "factory-default" read-only datastore is defined, that contains the data that will be copied over to the running datastore at reset. Internet Video Codec (netvc) ---------------------------- "