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-04-22 09:05:42 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-02-10, 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. 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-02-04, This document updates RFC 4861 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-03-09, 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-03-11, 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, PLC (IEEE 1901.2), and IEEE 802.15.4e (6tisch) 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-03-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 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-01-23, 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. "LLN Minimal Fragment Forwarding", Thomas Watteyne, Carsten Bormann, Pascal Thubert, 2019-03-11, This document gives an overview of LLN Minimal Fragment Forwarding. 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 document is a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly], which details the virtual Reassembly Buffer (VRB) implementation technique which reduces the latency and increases end-to-end reliability in route-over forwarding. "Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2019-02-03, Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. IPv6 Maintenance (6man) ----------------------- "IPv6 Segment Routing Header (SRH)", Clarence Filsfils, Stefano Previdi, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca, 2019-04-05, Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header. This document describes the Segment Routing Extension Header and how it is used by Segment Routing capable nodes. "IPv6 Router Advertisement IPv6-Only Flag", Robert Hinden, Brian Carpenter, Bjoern Zeeb, 2019-03-07, This document specifies a Router Advertisement Flag to indicate to hosts that the administrator has configured the router to advertise that the link is IPv6-Only. This document updates RFC4861 and RFC5175. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves, 2019-03-11, 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 from interface identifiers that change over time. Changing the interface identifier (and the global scope addresses generated from it) 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. "Discovering PREF64 in Router Advertisements", Lorenzo Colitti, Erik Kline, Jen Linkova, 2019-03-24, This document specifies a Router Advertisement option to communicate NAT64 prefixes to clients. 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-03-01, 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-04-05, 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, 2018-10-22, 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 a constrained version of [I-D.ietf-anima-bootstrapping-keyinfra]. "IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information", Diego Dujovne, Michael Richardson, 2019-03-25, In TSCH mode of IEEE802.15.4, as described by [RFC8180], 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-04-08, 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) ------------------------------------------------------------------- "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Goeran Selander, Carsten Bormann, 2018-10-22, Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. "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-02-21, This specification describes how to declare in a CBOR Web Token (CWT) 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 CBOR and CWTs rather than JSON and JWTs. "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", Francesca Palombini, Ludwig Seitz, Goeran Selander, Martin Gunnarsson, 2019-02-19, 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-03-08, 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-03-08, 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-03-08, This document describes a method to request and provision keying material in group communication scenarios where communications are 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 profiles of ACE to achieve communication security, proof-of-possession and server authentication. Automated Certificate Management Environment (acme) --------------------------------------------------- "CAA Record Extensions for Account URI and ACME Method Binding", Hugo Landau, 2019-01-15, The CAA DNS record allows a domain to communicate issuance policy to 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-03-04, 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. "ACME IP Identifier Validation Extension", Roland Shoemaker, 2019-02-14, 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, 2018-08-17, This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol which allows for domain control validation using TLS. "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock, Mary Barnes, Jon Peterson, 2019-03-25, This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates. "ACME Challenges Using an Authority Token", Jon Peterson, Mary Barnes, David Hancock, Chris Wendt, 2019-03-25, Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. "An ACME Profile for Generating Delegated STAR Certificates", Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2018-12-13, 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, Yang Yang, 2019-03-11, 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, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan, 2019-02-27, This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service such 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 Calendars, 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, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2018-11-28, Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offer a low delay delivery to the Resource Consumer. However, the base ALTO protocol has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [RFC7285]). This document proposes a set of Cost Metrics, 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. It currently documents Network Performance Cost Metrics reporting on network delay, jitter, packet loss, hop count, and bandwidth. These metrics may be exposed by an ALTO Server to allow applications to determine "where" to connect based on network performance criteria. Additional Cost Metrics involving ISP specific considerations or other network technologies may be documented in further versions of this draft. "Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery", Sebastian Kiesel, Martin Stiemerling, 2018-11-13, 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 Cost Type", Kai Gao, Young Lee, Sabine Randriamasy, Yang Yang, J. Zhang, 2019-03-11, The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] has defined cost maps and endpoint cost maps to provide basic network information. However, they provide only scalar (numerical or ordinal) cost mode values, which are insufficient to satisfy the demands of solving more complex network optimization problems. This document introduces an extension to the base ALTO protocol, namely the path-vector extension, which allows ALTO clients to query information such as the capacity region for a given set of flows (called co-flows). A non-normative example called co-flow scheduling is presented to illustrate the limitations of existing ALTO endpoint cost maps. After that, details of the extension are defined. "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, Xiao Lin, 2019-03-11, 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, Yang Yang, J. Zhang, 2019-03-11, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to domains of other entities, and by presenting those properties as maps, similar to the network and cost maps in ALTO. 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-03-11, 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, Michael Behringer, Steinthor Bjarnason, Kent Watsen, 2019-03-07, 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 certificate, 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 is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but 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-01-20, 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. "Constrained Voucher Artifacts for Bootstrapping Protocols", Michael Richardson, Peter van der Stok, Panos Kampanakis, 2019-03-25, 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 in 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. "Link Relation Types for Web Services", Erik Wilde, 2019-01-11, Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation, descriptions, or metadata for these Web services. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers; metadata is supposed to be information about a service's context. It also defines a link relation to identify status resources that are used to represent operational information about service status. "The Sunset HTTP Header Field", Erik Wilde, 2019-02-22, This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset. "Regular Expressions for Internet Mail", Sean Leonard, Joe Hildebrand, Tony Hansen, 2018-11-05, Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms. "SIP-based Messaging with S/MIME", Ben Campbell, Russ Housley, 2019-01-26, Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFC 3261, RFC 3428, and RFC 4975. "Well-Known Uniform Resource Identifiers (URIs)", Mark Nottingham, 2019-04-07, This memo defines a path prefix for "well-known locations", "/.well- known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785, and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. "New protocol elements for HTTP Status Code 451", Shivan Sahib, 2018-08-01, This document recommends additional protocol elements to Hypertext Transfer Protocol (HTTP) status code 451 (defined by RFC7725). Discussion of this document was conducted on the Human Rights Protocol Considerations Research Group mailing list https://www.irtf.org/mailman/listinfo/hrpc [1], briefly on the HTTPBIS Working Group mailing list ietf-http-wg@w3.org [2] and on https://lists.ghserv.net/mailman/listinfo/statuscode451 [3]. "The 'leaptofrogans' URI Scheme", Alexis Tamas, Benjamin Phister, Jean-Emmanuel Rodriguez, 2019-02-07, This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software enabling end users to browse Frogans sites. "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. "Update to the TRIP IANA Registry Rules Regarding Postal Addresses", Jari Arkko, Ted Hardie, 2018-12-04, This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information. This memo updates RFC 3219. "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. "vCard Format Extensions: Internet Corporation for Assigned Names and Numbers (ICANN) Extensions for the Registration Data Access Protocol (RDAP)", Scott Hollenbeck, Roger Carney, 2019-04-12, This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies. "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. 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, 2018-12-14, 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. "Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas Nandakumar, 2019-03-28, This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. "RTP Control Protocol (RTCP) Feedback for Congestion Control", Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho, 2018-12-23, 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. 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, 2018-11-14, Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols. "The Babel Routing Protocol", Juliusz Chroboczek, David Schinazi, 2019-03-27, 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-03-05, This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants. "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-02-06, The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This documents specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). This document updates RFC 6126bis. "HMAC authentication for the Babel routing protocol", Clara Do, Weronika Kolodziejak, Juliusz Chroboczek, 2019-03-09, This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. "YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark, 2019-03-08, This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. BGP Enabled ServiceS (bess) --------------------------- "BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro, 2019-03-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. "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. "(PBB-)EVPN Seamless Integration with (PBB-)VPLS", Ali Sajassi, Samer Salam, Nick Regno, Jorge Rabadan, 2019-02-01, This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This document specifies control-plane and forwarding behavior needed for auto-discovery of a VPN instance, multicast and unicast operation, as well as MAC-mobility operation in order to enable seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs. "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler, Gregory Mirsky, 2019-02-14, 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. "Updated processing of Control Flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2019-04-19, This document updates the meaning of the Control Flags field in the Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in RFC4761. This document updates RFC4761. "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, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, Erik Nordmark, 2018-11-04, 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. "Service Function Chaining using Virtual Networks with BGP VPNs", Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin, 2018-12-04, This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. "Yang Data Model for EVPN", Patrice Brissette, Himanshu Shah, Iftekhar Hussain, Kishore Tiruveedhula, Jorge Rabadan, 2019-03-11, This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. This document mainly focuses on EVPN and Ethernet-Segment instance framework. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, Ing-When Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula, 2018-10-22, 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. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2018-12-13, This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. "BGP Control Plane for NSH SFC", Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil, 2019-03-06, 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. "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com, 2018-12-21, 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. "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", Adrian Farrel, John Drake, Eric Rosen, Keyur Patel, Luay Jalil, 2019-02-26, 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-01-23, 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. "Framework for EVPN Designated Forwarder Election Extensibility", Jorge Rabadan, satyamoh@cisco.com, Ali Sajassi, John Drake, Kiran Nagaraj, Senthil Sathappan, 2019-01-24, An alternative to the Default Designated Forwarder (DF) selection algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to multi-homed Customer Equipment (CE) on a particular Ethernet Segment (ES) within a VLAN. In addition, the capability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF Election Finite State Machine in EVPN, therefore it updates the EVPN specification. "MVPN and MSDP SA Interoperation", Zhaohui Zhang, Leonard Giuliano, 2019-01-28, This document specifies the procedures for interoperation between MVPN Source Active routes and customer 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. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan, 2019-01-18, EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single- Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and a set of PE devices that they are connected to. Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to- Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. "Per multicast flow Designated Forwarder Election for EVPN", Ali Sajassi, mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake, 2019-03-08, [RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow). "Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing", Neeraj Malhotra, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, Avinash Lingala, 2019-03-25, 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 "MVPN/EVPN Tunnel Aggregation with Common Labels", Zhaohui Zhang, Eric Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands, 2018-12-18, The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD. (In some cases, a distinct upstream-assigned is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. "Yang Data Model for Multicast in MPLS/BGP IP VPNs", Yisong Liu, Feng Guo, Stephane Litkowski, Xufeng Liu, Robert Kebler, Mahesh Sivakumar, 2019-03-05, This document defines a YANG data model that can be used to configure and manage multicast in MPLS/BGP IP VPNs. "EVPN Operations, Administration and Maintenance Requirements and Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald Eastlake, 2019-02-26, This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. "EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, Eric Rosen, John Drake, Wen Lin, Jim Uttaro, Adam Simpson, 2019-03-06, EVPN is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where 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-03-27, The 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. Intent of this draft is to enumerate a set of design considerations applicable to mobility across EVPN IRB use cases and define generic sequence number assignment procedures to address these IRB use cases. 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, 2018-11-08, 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-02-21, 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-02-19, 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, 2018-12-26, This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks. "BFD Encapsulated in Large Packets", Jeffrey Haas, Albert Fu, 2019-02-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-02-26, 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-01-31, 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-01-23, 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-02-24, 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, 2018-12-18, 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, 2018-12-11, This document describes a hybrid performance measurement method for multicast service over Bit Index Explicit Replication (BIER) domain. "BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Gregory Mirsky, 2018-10-21, 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. "Traffic Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth, 2018-10-23, This document proposes an architecture for BIER-TE: Traffic Engineering for Bit Index Explicit Replication (BIER). BIER-TE shares part of its architecture with BIER as described in [RFC8279]. It also proposes to share the packet format with BIER. BIER-TE forwards and replicates packets like BIER based on a BitString in the packet header but it does not require an IGP. It does support traffic engineering by explicit hop-by-hop forwarding and loose hop forwarding of packets. It does support Fast ReRoute (FRR) for link and node protection and incremental deployment. Because BIER-TE like BIER operates without explicit in-network tree- building but also supports traffic engineering, it is more similar to SR than RSVP-TE. "PIM Signaling Through BIER Core", Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, mankamana mishra, Zhaohui Zhang, 2019-01-24, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits 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, 2018-11-16, This document specifies general rules for interaction between the BAR (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ OSPFv2 Extensions for BIER. "Use of BIER Entropy for Data Center CLOS Networks", Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride, 2018-11-05, 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, 2018-11-28, Bit Index Explicit Replication (BIER) can be used as provider tunnel for MVPN/GTM [RFC6514] [RFC7716] or EVPN BUM [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 the MVPN/EVPN PEs are assumed to be BIER capable - they are BFIRs/BFERs. 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 BFR (connected directly or indirectly via a tunnel) of a PE remove the BIER header and send the payload to the PE. "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Debashish Purkayastha, Akbar Rahman, Dirk Trossen, Toerless Eckert, 2019-02-12, HTTP Level multicast, using BIER, is described as a use case in 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. A realization of "HTTP Multicast" over "IP Multicast" is described. 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. 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. "BIER MTU Discovery", Stig Venaas, IJsbrand Wijnands, Les Ginsberg, Mahesh Sivakumar, 2019-02-27, This document defines an IGP based mechanism for discovering the MTU of a BIER sub-domain. This document defines extensions to OSPF and IS-IS, but other protocols could potentially be extended. MTU discovery is usually done for a given path, while this document defines it for a sub-domain. This allows the computed MTU to be independent of the set of receivers. Also, the MTU is independent of rerouting events within the sub-domain. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore Tiruveedhula, 2018-11-26, 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-03-05, 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. Calendaring Extensions (calext) ------------------------------- "Event Publishing Extensions to iCalendar", Michael Douglass, 2019-04-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. "CalDAV Managed Attachments", Cyrus Daboo, Arnaud Quillaud, Ken Murchison, 2019-03-05, This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP. "JSCalendar: A JSON representation of calendar data", Neil Jenkins, Robert Stepanek, 2019-03-05, 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 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. "CalDAV Extension for scheduling controls", Bron Gondwana, 2019-03-26, This document adds headers to control and restrict the scheduling behaviour of CalDAV servers when updating calendaring resources. Captive Portal Interaction (capport) ------------------------------------ "CAPPORT Architecture", Kyle Larose, David Dolson, 2018-12-27, 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-03-11, This document describes an HTTP API that allows clients to interact with a Captive Portal system. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Concise Binary Object Representation (CBOR)", Carsten Bormann, Paul Hoffman, 2019-01-15, 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. "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures", Henk Birkholz, Christoph Vigano, Carsten Bormann, 2019-03-24, This document proposes a notational convention to express CBOR data structures (RFC 7049, Concise Binary Object Representation). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. "Concise Binary Object Representation (CBOR) Tags for Typed Arrays", Johnathan Roatch, Carsten Bormann, 2019-03-05, 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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation", Giovanni Martinelli, Gabriele Galimberti, Young Lee, Fatai Zhang, 2019-03-04, 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. "Ethernet Traffic Parameters with Availability Information", Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2019-03-06, A packet switching network may contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment (e.g., climate). Availability is typically used for describing these links when doing network planning. This document introduces an optional Availability TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a Generalized Multi- Protocol Label Switching (GMPLS) Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object. "A framework for Management and Control of DWDM optical interface parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, Julien Meuric, 2018-11-13, 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-03-24, 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 Microwave Radio Link", Jonas Ahlberg, Min Ye, Xi Li, Daniela Spreafico, Marko Vaupotic, 2018-11-28, This document defines a YANG data model for control and management of the radio link interfaces, and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available also for other interface types. RFC Ed. Note // RFC Ed.: replace all XXXX throughout the document with actual RFC numbers and remove this note "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-02-25, 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-02-25, This document describes the YANG data model for OTN Tunnels. "YANG Alarm Module", Stefan Vallin, Martin Bjorklund, 2019-04-11, This document defines a YANG module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. "YANG data model for Flexi-Grid Optical Networks", Universidad de Madrid, Daniel Perdices, Victor Lopezalvarez, Oscar de Dios, Daniel King, Young Lee, Gabriele Galimberti, 2019-03-24, 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, Dhruv Dhody, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, Ricard Vilata, 2019-03-07, 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-03-11, 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. "Information Encoding for WSON with Impairments Validation", Giovanni Martinelli, Young Lee, Gabriele Galimberti, Fatai Zhang, 2019-01-04, Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) function might be required in Wavelength Switched Optical Networks (WSON) that already support RWA. This document defines proper encoding to support this operation. It goes in addition to the available impairment-free WSON encoding and it is fully compatible with it. As the information model, the encoding is independent from control plane architectures and protocol implementations. Its definitions can be used in related protocol extensions. "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Giuseppe Fioccola, Kwang-koog Lee, Young Lee, Dhruv Dhody, Daniele Ceccarelli, 2019-03-06, This document provides a YANG data model for Layer 1 Connectivity Service Model (L1CSM). The intent of this document is to provide a transport service model exploiting YANG data model, which can be utilized by a client network controller to initiate a service request connectivity request as well as retrieving service states toward a transport network controller communicating with the client controller. This YANG model is NMDA-compliant. "YANG data model for Flexi-Grid media-channels", Universidad de Madrid, Daniel Perdices, Victor Lopezalvarez, Oscar de Dios, Daniel King, Young Lee, Gabriele Galimberti, 2019-03-24, This document defines a YANG model for managing flexi-grid optical media channels, complementing the information provided by the flexi-grid topology model. It is also grounded on other defined YANG abstract models. "A YANG Data Model for Microwave Topology", Min Ye, Aihua Guo, Jonas Ahlberg, Xi Li, Daniela Spreafico, 2019-03-07, This document defines a YANG data model to describe the topologies of microwave/millimeter. "Applicability of GMPLS for B100G Optical Transport Network", Qilei Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti, 2019-02-27, 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. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application", Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller, 2019-03-26, This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions. "A YANG model to manage the optical interface parameters for an external transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel, 2019-03-26, 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, Haomian Zheng, Italo Busi, Nicola Sambo, Victor Lopezalvarez, Gabriele Galimberti, Giovanni Martinelli, Luc Auge, Julien Meuric, Dieter Beller, Sergio Belotti, Griseri Enrico, Gert Grammel, 2019-04-15, 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. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, Phil Sorber, 2019-03-11, 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-03-31, The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests 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 Metadata and FCI interfaces are derived from requirements raised by Open Caching but are applicable to CDNI use cases in general. "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile, Sanjay Mishra, 2018-11-28, 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-03-31, 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-01-24, 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-02-06, 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-02-06, 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-01-10, 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-01-10, 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-01-10, This document defines the Matroska tags, namely the tag names and their respective semantic meaning. Crypto Forum (cfrg) ------------------- "Hash-Based Signatures", David McGrew, Michael Curcio, Scott Fluhrer, 2019-01-07, This note describes a digital signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and naturally resist side-channel attacks. Unlike most other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2019-03-11, This document describes SPAKE2 and its augmented variant SPAKE2+, which are protocols 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 prime order group, is computationally efficient, and SPAKE2 (but not SPAKE2+) has a security proof. "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2018-11-23, This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description together with sample code and test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. "Re-keying Mechanisms for Symmetric Keys", Stanislav Smyshlyaev, 2019-03-25, A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called "key lifetime". This specification describes a variety of methods to increase the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and on block ciphers, that can be used with modes of operations such as CTR, GCM, CBC, CFB and OMAC. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. "KangarooTwelve", Benoit Viguier, 2019-02-07, 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. "Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin, Dimitrios Papadopoulos, Jan Vcelak, 2019-02-08, 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-03-11, 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", Sam Scott, Nick Sullivan, Christopher Wood, 2019-03-11, This document specifies a number of algorithms that may be used to encode or hash an arbitrary string to a point on an Elliptic Curve. "XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305", Scott Arciszewski, 2018-12-18, 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 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. 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-17, This document defines how to use the WebRTC data channel mechanism in order 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, 2018-09-21, 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-03-11, 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. "Reusable Interface Definitions for Constrained RESTful Environments", Zach Shelby, Michael Koster, Christian Groves, Jintao Zhu, Bill Silverajan, 2019-03-11, This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Parameter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines an Interface Description attribute value to describe resources conforming to a particular interface. Editor's notes: o The git repository for the draft is found at https://github.com/ "CBOR Encoding of Data Modeled with YANG", Michel Veillette, Ivaylo Petrov, Alexander Pelov, 2019-04-08, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications 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-03-07, 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 "Object Security for Constrained RESTful Environments (OSCORE)", Goeran Selander, John Mattsson, Francesca Palombini, Ludwig Seitz, 2019-03-06, This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although being an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates [RFC7252]. "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2019-03-11, The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. "YANG Schema Item iDentifier (SID)", Michel Veillette, Alexander Pelov, Ivaylo Petrov, 2019-03-28, YANG Schema Item iDentifiers (SID) are globally unique 64-bit unsigned numbers 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, 2018-11-12, 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. CoMI 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", Kerry Lynn, Peter van der Stok, Michael Koster, Christian Amsuess, 2019-03-11, 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-03-23, 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 updated Token processing requirements for clients ensure secure 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-03-08, 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. "Uniform Resource Names for Device Identifiers", Jari Arkko, Cullen Jennings, Zach Shelby, 2018-10-22, This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. "Multipart Content-Format for CoAP", Thomas Fossati, Klaus Hartke, Carsten Bormann, 2019-03-08, 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-02-26, 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-03-11, 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-03-11, 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. CBOR Object Signing and Encryption (cose) ----------------------------------------- "Use of the Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", Russ Housley, 2019-04-05, This document specifies the conventions for using the HSS/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 CBOR Object Signing and Encryption (COSE): Structures and Process", Jim Schaad, 2019-03-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-03-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-03-11, The CBOR Signing And Encrypted Message (COSE) structure syntax uses the COSE Key structure for placing keys in a message. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Contributing to this document The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at . Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. "CBOR Object Signing and Encryption (COSE): Hash Algorithms", Jim Schaad, 2019-03-11, The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are however circumstances where hash algorithms are used: Indirect signatures where the hash of one or more contents are signed. X.509 certificate or other object identification by the use of a thumbprint. 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-03-27, 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, 2018-06-27, This document describes the conventions 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-01-02, 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-01-16, This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally obsoletes and moves to Historic RFC4345. "Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH) protocol", Ben Harris, Loganaden Velvindron, 2019-01-16, This document describes the use of the Ed25519 and Ed448 digital signature algorithm in the Secure Shell (SSH) protocol. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking Use Cases", Ethan Grossman, 2018-12-19, This draft presents use cases from diverse industries which have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for DetNet. For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. The Use Case Common Themes section then extracts and enumerates the set of common properties implied by these use cases. "Deterministic Networking Problem Statement", Norman Finn, Pascal Thubert, 2018-12-19, This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. "Deterministic Networking Architecture", Norman Finn, Pascal Thubert, Balazs Varga, Janos Farkas, 2019-03-09, 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-03-02, 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 7. "DetNet Flow Information Model", Janos Farkas, Balazs Varga, Rodney Cummings, Yuanlong Jiang, 2019-03-08, This document describes flow and service information model for Deterministic Networking (DetNet). The DetNet service is provided either for a Layer 3 or a Layer 2 flow. This document provides DetNet flow and service information model both for Layer 3 and Layer 2 flows in an integrated fashion. "DetNet MPLS Data Plane Encapsulation", Jouni Korhonen, Balazs Varga, 2019-03-10, This document specifies the Deterministic Networking data plane when operating over an MPLS Packet Switched Networks. "DetNet IP Data Plane Encapsulation", Jouni Korhonen, Balazs Varga, 2019-03-10, This document specifies the Deterministic Networking data plane when operating in an IP packet switched network. "Deterministic Networking (DetNet) Configuration YANG Model", Xuesong Geng, Mach Chen, Zhenqiang Li, Reshad Rahman, 2019-03-25, 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). "Deterministic Networking (DetNet) Topology YANG Model", Xuesong Geng, Mach Chen, Zhenqiang Li, Reshad Rahman, 2019-01-25, This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). Dynamic Host Configuration (dhc) -------------------------------- "YANG Data Model for DHCPv6 Configuration", Yong Cui, Linhui Sun, Ian Farrer, Sladjana Zechlin, Zihao He, 2019-03-09, This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays, and clients. "SLAP quadrant selection options for DHCPv6", Carlos Bernardos, Alain Mourad, 2019-03-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. "Link-Layer Addresses Assignment Mechanism for DHCPv6", Bernie Volz, Tomek Mrugalski, Carlos Bernardos, 2019-04-17, 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. 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. "Diameter Overload Rate Control", Steve Donovan, Eric Noel, 2019-02-11, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. Requirements "Diameter Agent Overload and the Peer Overload Report", Steve Donovan, 2017-03-22, This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements "Diameter Load Information Conveyance", Ben Campbell, Steve Donovan, Jean-Jacques Trottin, 2017-03-22, RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. This document defines a mechanism for conveying of Diameter load information. Dispatch (dispatch) ------------------- "ECMAScript Media Types Updates", Myles Borins, Mathias Bynens, Matthew Miller, Bradley Farias, 2019-02-22, 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) -------------------------------------------------------------------- "Authenticated Received Chain (ARC) Protocol", Kurt Andersen, Brandon Long, Seth Blank, Murray Kucherawy, 2018-12-18, The Authenticated Received Chain (ARC) protocol 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. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. "Recommended Usage of the Authenticated Received Chain (ARC)", Steven Jones, Kurt Andersen, John Rae-Grant, J. Adams, 2018-10-22, 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. "Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol", Kurt Andersen, Seth Blank, John Levine, 2019-03-07, The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination. Initial development of ARC has been done with a single allowed signing algorithm, but parallel work in the DCRUP working group (https://datatracker.ietf.org/wg/dcrup/about/) is expanding the supported algorithms. This specification defines how to extend ARC for multiple signing algorithms. "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 2019-01-28, This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes [RFC7601]. "DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)", Scott Kitterman, 2019-04-09, 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. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. "E-mail Authentication for Internationalized Mail", John Levine, 2019-04-11, SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. Distributed Mobility Management (dmm) ------------------------------------- "On Demand Mobility Management", Alper Yegin, Danny Moses, Seil Jeon, 2019-02-22, 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-03-11, 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 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-03-11, This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. Domain Name System Operations (dnsop) ------------------------------------- "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2019-01-09, 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. ] "A Common Operational Problem in DNS Servers - Failure To Communicate.", Mark Andrews, Ray Bellis, 2019-02-25, The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other zone operators to apply to mitigate the problem. The document does not look at the DNS data itself, just the structure of the responses. "C-DNS: A DNS Packet Capture Format", John Dickinson, Jim Hague, Sara Dickinson, Terry Manderson, John Bond, 2018-12-12, This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic monitoring applications. "Address-specific DNS aliases (ANAME)", Tony Finch, Evan Hunt, Peter van Dijk, Anthony Eden, Willem Mekking, 2019-04-15, This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for type A and AAAA 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-01-02, 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-03-11, 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. "Serving Stale Data to Improve DNS Resiliency", David Lawrence, Warren Kumari, Puneet Sood, 2019-04-16, 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. It updates the definition of TTL from [RFC1034], [RFC1035], and [RFC2181] to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. 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. "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", Paul Wouters, Ondrej Sury, 2019-04-20, The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC6944. "Message Digest for DNS Zones", Duane Wessels, Piet Barber, Matt Weinberg, Warren Kumari, Wes Hardaker, 2019-02-13, 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. "Secret Key Transaction Authentication for DNS (TSIG)", Francis Dupont, Stephen Morris, Paul Vixie, Donald Eastlake, Olafur Gudmundsson, Brian Wellington, 2019-03-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-03-07, Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on the same server, such as on a loopback address. This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. This draft will update RFC 7706. See Section 1.1 for a list of topics that will be added in the update. [ Ed note: Text inside square brackets ([]) is additional background information, answers to freqently 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-kh-dnsop-7706bis. The most recent version of the document, open issues, and so on should all be available there. The authors gratefully accept pull requests. ] "DNS Query Name Minimisation to Improve Privacy", Stephane Bortzmeyer, Paul Hoffman, 2019-03-23, This document describes techniques called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME to the upstream name server. This document obsoletes RFC 7816. This document is part of the IETF DNSOP (DNS Operations) Working Group. The source of the document, as well as a list of open issues, is at NOTE FOR THE DNSOP WORKING GROUP: There is still much work to be done in this draft. Future versions of this draft will contain descriptions of different minimisation implementation choices that have been made since the RFC 7816 first came out, as well as deployment experience. "Multi Provider DNSSEC models", Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak, David Blacka, 2019-03-11, 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. 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-03-24, 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. "Service Discovery Road Map", Stuart Cheshire, 2018-10-23, Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments. "Device Pairing Design Issues", Daniel Kaiser, Christian Huitema, 2018-10-23, This document discusses issues and problems occuring in the design of device pairing mechanism. It presents experience with existing pairing systems and general user interaction requirements to make the case for "short authentication strings". It then reviews the design of cryptographic algorithms designed to maximise the robustness of the short authentication string mechanisms, as well as implementation considerations such as integration with TLS. "Multicast DNS Discovery Relay", Ted Lemon, Stuart Cheshire, 2019-03-11, This document complements the specification of the Discovery Proxy for Multicast DNS-Based Service Discovery. It describes a lightweight relay mechanism, a Discovery Relay, which, when present on a link, allows remote clients, not attached to that link, to perform mDNS discovery operations on that link. "Service Registration Protocol for DNS-Based Service Discovery", Stuart Cheshire, Ted Lemon, 2019-03-11, The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. DNS Over HTTPS (doh) -------------------- "Associating a DoH Server with a Resolver", Paul Hoffman, 2019-03-24, Browsers and web applications may want to know if there are one or more DoH servers associated with the DNS recursive resolver that the operating system is already using. This would allow them to get DNS responses from a resolver that the user (or, more likely, the user's network administrator) has already chosen. This document describes two protocols for a resolver to tell a client what its associated DoH servers are. It also describes a protocol for a client to find out the address of the resolver it is using, if it cannot find that address by an operating system API or some other means. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Daniel Migault, Stefan Fouant, Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2019-01-10, The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents 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 (DDoS) Open Threat Signaling Requirements", Andrew Mortensen, Reddy K, Robert Moskowitz, 2019-03-25, This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Andrew Mortensen, Reddy K, Flemming Andreasen, Nik Teague, Rich Compton, 2019-04-03, 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-03-28, 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-03-28, 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, 2019-01-21, 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) Server Discovery", Mohamed Boucadair, Reddy K, Prashanth Patil, 2019-04-17, 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. DNS PRIVate Exchange (dprive) ----------------------------- "Recommendations for DNS Privacy Service Operators", Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij, Allison Mankin, 2019-03-11, This document presents operational, policy and security considerations for DNS 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 DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]). Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane, 2018-11-30, 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-04-09, 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-03-31, 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-01-31, 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-02-28, 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. "BPSec Interoperability Security Contexts", Edward Birrane, 2019-03-26, This document defines an integrity security context and a confidentiality security context suitable for testing the interoperability of Bundle Protocol Security (BPSec) implementations. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "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-01-17, 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, 2018-10-23, 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-03-11, 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 3rd Generation Authentication and Key Agreement (EAP-AKA')", Jari Arkko, Vesa Lehtovirta, Vesa Torvinen, Pasi Eronen, 2019-01-17, The 3rd Generation 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 is an update of the specification for EAP-AKA'. This version obsoletes RFC 5448. 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 instead of SHA-1 as in EAP-AKA. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan Bosch, 2019-01-24, The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. "Sieve Extension: File Carbon Copy (Fcc)", Ken Murchison, Bron Gondwana, 2019-01-13, The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2", Alexey Melnikov, Barry Leiba, 2019-03-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-02-16, 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. GitHub Integration and Tooling (git) ------------------------------------ "GitHub Configuration for IETF Working Groups", Alissa Cooper, Paul Hoffman, 2019-03-07, 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, 2019-04-12, 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]. Global Routing Operations (grow) -------------------------------- "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2019-03-24, 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-03-24, 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. "Well-Known Community Policy Behavior", Jay Borkenhagen, Randy Bush, Ron Bonica, Serpil Bayraktar, 2019-03-10, Well-Known BGP Communities are manipulated inconsistently by current implementations. This results in difficulties for operators. Network operators are encouraged to deploy consistent community handling across their networks, taking the inconsistent behaviors from the various BGP implementations they operate into consideration. Also, BGP implementors are expected to not create any further inconsistencies from this point forward. "RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering", Job Snijders, Massimiliano Stucchi, 2019-03-05, This document describes a way to define groups of Autonomous System numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide a mechanism to be used by operators for filtering BGP-4 [RFC4271] announcements. "Revision to Registration Procedures for Multiple BMP Registries", John Scudder, 2018-12-09, 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-04-19, Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a solution for detection and mitigation route leaks which is based on conveying route-leak protection (RLP) information in a Border Gateway Protocol (BGP) community. The RLP information is carried in a new well-known transitive BGP community, called the RLP community. The RLP community helps with detection and mitigation of route leaks at ASes downstream from the leaking AS (in the path of the BGP update). This is an inter-AS (multi-hop) solution mechanism. This solution complements the intra-AS (local AS) route-leak avoidance solution that is described in ietf-idr-bgp-open-policy draft. 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, 2017-12-18, 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. In doing so, the main goal is to still deliver similar security properties to HIPv2. 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) ------------------------- "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. "Homenet Naming and Service Discovery Architecture", Ted Lemon, Daniel Migault, Stuart Cheshire, 2018-10-23, This document describes how names are published and resolved on homenets, and how hosts are configured to use these names to discover services on homenets. It presents the complete architecture, and describes a simple subset of that architecture that can be used in low-cost homenet routers. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Guidelines for Human Rights Protocol and Architecture Considerations", Niels ten Oever, Gurshabad Grover, 2019-03-11, 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, Amelia Andersdotter, 2019-02-27, The IETF cannot ordain which standards or protocols are to be used on network, but the standards developing process in the IETF has a normative effect. Among other things the standardisation work at the IETF has implications on what is perceived as technologically possible and useful where networking technologies are being deployed, and its standards output reflect was is considered by the technical community as feasible and good practice. Because it mediates many aspects of modern life, and therefore contributes to the ordering of societies and communities, the consideration of the politics and (potential) impact of protocols should be part of the standardization and development process. If the technical community refuses to take up this responsibility, it should accept that others, such as governments, will take up this role. "Freedom of Association on the Internet", Niels ten Oever, Gisela de Acha, 2019-02-19, This document establishes the causal 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) ------------------------------------- "HTTP Client Hints", Ilya Grigorik, 2019-03-11, HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. This document defines two response headers, Accept-CH and Accept-CH- Lifetime, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." It also defines an initial set of Client Hints. "Structured Headers for HTTP", Mark Nottingham, Poul-Henning Kamp, 2019-04-17, This document describes a set of data types and algorithms associated with them that are intended to make it easier and safer to define and handle HTTP header fields. It is intended for use by new specifications of HTTP header fields as well as revisions of existing header field specifications when doing so does not cause interoperability issues. "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, 2018-10-23, 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. "Building Protocols with HTTP", Mark Nottingham, 2018-11-10, HTTP is often used as a substrate for other application protocols (a.k.a. HTTP-based APIs). This document specifies best practices for such protocols' use of HTTP when they are defined for diverse implementation and broad deployment (e.g., in standards efforts). "HTTP Representation Variants", Mark Nottingham, 2019-03-25, This specification introduces an alternative way to communicate a secondary cache key for a HTTP resource, using the HTTP "Variants" and "Variant-Key" response header fields. Its aim is to make HTTP proactive content negotiation more cache-friendly. "HTTP Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 2019-03-09, 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-03-09, 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-03-09, 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. "CDN Loop Detection", Stephen Ludin, Mark Nottingham, Nick Sullivan, 2019-02-03, This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop. "The Cache HTTP Response Header", Mark Nottingham, 2019-01-27, To aid debugging, HTTP caches often append headers to a response detailing how they handled the request. This specification codifies that practice and updates it for HTTP's current caching model. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, Henk Birkholz, 2019-01-02, 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, 2018-10-22, 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-03-11, 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-03-11, 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 with IPsec. The document focuses in the NSF Facing Interface by providing models for Configuration and State data model 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-04-04, 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 managed objects and relationship among these objects needed to build the interface. The information model is organized based on the "Event-condition-Event" (ECA) policy model defined by a capability information model for Interface to Network Security Functions (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-03-28, This document defines a YANG data model for configuring security policy rules on network security functions. The YANG data model in this document is corresponding to the information model for Network Security Functions (NSF)-Facing Interface in Interface to Network Security Functions (I2NSF). "I2NSF Capability YANG Data Model", Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, Qiushi Lin, 2019-03-28, This document defines a YANG data model for capabilities of various Network Security Functions (NSFs) in Interface to Network Security Functions (I2NSF) framework to cetrally manage capabilities of varios NSFs. "I2NSF Registration Interface YANG Data Model", Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J., PARK, 2019-03-28, This document defines an information model and a YANG data model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System (DMS). The objective of these information and data models is to support NSF capability registration and query via I2NSF Registration Interface. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: "This version of this YANG module is part of RFC XXXX;" "RFC XXXX: I2NSF Registration Interface YANG Data Model" "reference: RFC XXXX" Please update the "revision" date of the YANG module. "I2NSF NSF Monitoring YANG Data Model", Jaehoon Jeong, Chaehong Chung, Susan Hares, Liang Xia, Henk Birkholz, 2019-03-11, This document proposes an information model and the corresponding YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed in a comprehensive way, it is possible to detect the indication of malicious activity, anomalous behavior or the potential sign of denial of service attacks in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for monitoring NSFs along with a YANG data diagram, but also the corresponding YANG data model for monitoring NSFs. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: "This version of this YANG module is part of RFC 6087;" "RFC XXXX: I2NSF NSF Monitoring YANG Data Model" "reference: RFC 6087" Please update the "revision" date of the YANG module. Interface to the Routing System (i2rs) -------------------------------------- "A YANG Data Model for Layer-2 Network Topologies", Jie Dong, Xiugang Wei, Qin Wu, 2018-10-22, This document defines a YANG data model for Layer 2 network topologies. Internet Architecture Board (iab) --------------------------------- "The Harmful Consequences of the Robustness Principle", Martin Thomson, 2019-03-10, 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. For a protocol that is actively maintained, the Postel's robustness principle can, and should, be avoided. IETF Administrative Support Activity 2 (iasa2) ---------------------------------------------- "RFC Editor Model (Version 2)", Olaf Kolkman, Joel Halpern, Robert Hinden, 2019-01-07, The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IASA and related structures with those defined by the IASA 2.0 Model. [RFC Editor: Please remove the following paragraph prior to publication.] The IASA2 WG requests that the IAB publish this replacement for RFC 6635. "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. "Independent Submission Editor Model", Nevil Brownlee, Robert Hinden, 2019-01-07, This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC). This version obsoletes RFC 6548 to replace all references to the IASA and related structures with those defined by the IASA 2.0 Model. [RFC Editor: Please remove the following paragraph prior to publication.] The IASA2 WG requests that the IAB publish this replacement for RFC 6548. "Update to the IETF Anti-Harassment Procedures for the Replacement of the IAOC with the IETF Administration LLC", Pete Resnick, Adrian Farrel, 2019-04-05, 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 Adminstrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms. RFC 7776 contained updated 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. "Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries", Russ Housley, Olaf Kolkman, 2018-12-06, This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries. "Defining the Role and Function of IETF Protocol Parameter Registry Operators", Danny McPherson, Olaf Kolkman, John Klensin, Geoff Huston, IAB, 2018-12-10, Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. "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-03-26, 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 based on RFC3777 and RFC7437 and has been updated to reflect the changes introduced by IASA 2.0. This document obsoletes RFC7437 and RFC8318. "The RFC Series and RFC Editor", Russ Housley, Leslie Daigle, 2019-04-15, This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. Cover Note: {{ RFC Editor: Please remove this cover note prior to publication. }} The IASA2 WG asks the IAB to publish this replacement for RFC 4844. The document is changed for alignment with the new structure for the IETF Administrative Support Activity (IASA), eliminating all references to the IETF Administrative Oversight Committee (IAOC). "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", Russ Housley, Tim Polk, Peter Saint-Andre, 2018-12-06, The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. "IETF Working Group Guidelines and Procedures", Scott Bradner, Rich Salz, 2018-10-20, The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. "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-02-14, 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-04-17, During the process of creating a peer-to-peer connection, 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. Information-Centric Networking (icnrg) -------------------------------------- "CCNx Semantics", Marc Mosko, Ignacio Solis, Christopher Wood, 2019-01-24, This document describes the core concepts of the Content Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a Control message called an InterestReturn, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. This document is a product of the Information Centric Networking research group (ICNRG). "CCNx Messages in TLV Format", Marc Mosko, Ignacio Solis, Christopher Wood, 2019-01-24, This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification. This document is a product of the Information Centric Networking research group (ICNRG). "Research Directions for Using ICN in Disaster Scenarios", Jan Seedorf, Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2019-02-20, 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. "Information-Centric Networking (ICN): CCN and NDN Terminology", Bastiaan Wissingh, Christopher Wood, Alex Afanasyev, Lixia Zhang, David Oran, Christian Tschudin, 2019-03-11, Information Centric Networking (ICN) is a new 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 (CCN) 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 projects. While there are other ICN architectures, they are not part of the NDN and CCN vision and as such are out of scope for this document. "Design Considerations for Applying ICN to IoT", Ravi Ravindran, Yanyong Zhang, Luigi Grieco, Anders Lindgren, Jeff Burke, Bengt Ahlgren, Aytac Azgin, 2018-10-22, 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-03-10, 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-03-07, 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. "MAP-Me : Managing Anchorless Mobility in Content Centric Networking", Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini, 2018-10-22, 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-03-11, 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. "Requirements for Name Resolution Service in ICN", Jungha Hong, Taewan You, Yong-Geun Hong, Lijun Dong, Cedric Westphal, Ved Kafle, Borje Ohlman, 2019-03-11, This document discusses the motivation and requirements 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 towards the object location. "Architectural Considerations of ICN using Name Resolution Service", Jungha Hong, Taewan You, Yong-Geun Hong, 2019-03-11, 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-03-08, In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LoWPAN networks is defined. 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. Inter-Domain Routing (idr) -------------------------- "BGP Bestpath Selection Criteria Enhancement", Rajiv Asati, 2018-12-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 desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Kevin Wang, 2019-04-03, 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-03-26, The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs and other features, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC4271 by providing an extension to BGP to extend its current maximum message size from 4096 octets to 65535 octets for all except the OPEN message. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra, 2018-11-05, This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 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-02-26, 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-04-08, 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. "BGP Dissemination of L2VPN Flow Specification Rules", Hao Weiguo, Donald Eastlake, Jim Uttaro, Stephane Litkowski, Shunwan Zhuang, 2019-01-03, This document defines a BGP flow-spec extension to disseminate L2 VPN Ethernet traffic filtering rules. SAFI=134 in [RFC5575] 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, 2018-10-23, 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-03-24, 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-03-11, 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, 2019-03-25, 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", Eric Rosen, Keyur Patel, Gunter Van de Velde, 2019-02-22, 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-03-04, 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, 2018-12-13, 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-04-18, 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 draft defines extensions to the BGP Link-state address-family in order to carry segment routing information via BGP. "Dissemination of Flow Specification Rules", Susan Hares, Christoph Loibl, Robert Raszuk, Danny McPherson, Martin Bacher, 2019-04-12, 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, 2018-12-17, 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-02-15, Route Leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes according to operator configuration options, 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, RS, RS-client, internal) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an iOTC attribute according to agreed relationship allowing prevention of route leaks. "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State", Jeff Tantsura, Uma Chunduri, Gregory Mirsky, Siva Sivabalan, Nikos Triantafillis, 2019-02-19, 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 logically centralized entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Dhanendra Jain, Paul Mattes, Eric Rosen, Steven Lin, 2018-11-21, 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, 2018-12-13, 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, 2018-10-22, 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, Shaowen Ma, 2019-04-07, This document describes the process to build BGP-LS key parameters in multi-domain scenario, defines one new BGP-LS NLRI type(Stub Link NLRI) and some new inter-AS TE related TLVs for BGP-LS to let SDN controller retrieve the network topology automatically under various environments. Such process and extension 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, 2018-11-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". Internet Area Working Group (intarea) ------------------------------------- "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2019-03-08, 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. "Extensions for Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Fred Templin, 2019-03-08, This specification defines a set of the initial optional extensions for Generic UDP Encapsulation (GUE). "Discovering Provisioning Domain Names and Data", Pierre Pfister, Eric Vyncke, Tommy Pauly, David Schinazi, Wenqin Shao, 2019-03-08, An increasing number of hosts access the Internet via multiple interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix configurations context. This document describes a way for hosts to identify such contexts, called Provisioning Domains (PvDs), where Fully Qualified Domain Names (FQDNs) act as PvD identifiers. Those identifiers are advertised in a new Router Advertisement (RA) option and, when present, are associated with the set of information included within the RA. Based on this FQDN, hosts can retrieve additional information about their network access characteristics via an HTTP over TLS query. This allows applications to select which Provisioning Domains to use as well as to provide configuration parameters to the transport layer and above. "IP Fragmentation Considered Fragile", Ron Bonica, Fred Baker, Geoff Huston, Robert Hinden, Ole Troan, Fernando Gont, 2019-02-12, This document describes IP fragmentation and explains how it reduces the reliability of 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-03-29, 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-03-29, 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-03-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, 2018-11-28, 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-03-04, 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-03-12, 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-03-04, 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. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Split DNS Configuration for IKEv2", Tommy Pauly, Paul Wouters, 2019-03-11, This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol Version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split tunnel configurations. "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-04-06, Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce 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, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. "Intermediate Exchange in the IKEv2 Protocol", Valery Smyslov, 2018-12-03, This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. "IKEv2 Notification Status Types for IPv4/IPv6 Coexistence", Mohamed Boucadair, 2018-11-08, 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-03-11, This document defines two new Traffic Selector (TS) Types for Internet Key Exchange version 2 to add support for Mandatory Access Control (MAC) security labels, also known as "Labeled IPsec". The two new TS Types are TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL, which are identical to their non- seclabel namesakes except for the addition of a variable length opaque field specifying the security label. These new Traffic Selector Types facilitate negotiating security labels as an additional selector of the Security Policy Database to further restrict the type of traffic allowed to be send and received over the IPsec SA. IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)", Alexandre Petrescu, Nabil Benamar, Jerome Haerri, Jong-Hyouk Lee, Thierry Ernst, Thierry Ernst, 2019-04-18, In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Jaehoon Jeong, 2019-03-24, 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 surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, it presents a problem exploration for key aspects in IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document discusses a problem statement to evaluate the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. 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) -------------------------------- "JSON Meta Application Protocol", Neil Jenkins, Chris Newman, 2019-03-20, This document specifies a protocol for clients to efficiently query, fetch and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation, and out-of-band binary data upload/download. "JMAP (JSON Meta Application Protocol) for Mail", Neil Jenkins, Chris Newman, 2019-03-07, This document specifies a data model for synchronising email data with a server using JMAP (the JSON Meta Application Protocol). Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. "Handling Message Disposition Notification with JMAP", Raphael Ouazana, 2019-03-07, 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-03-10, 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. Open Issues o Should push over WebSocket make use of the EventSource Last-Event- ID request header field (or a similar facility; e.g., as an extra query parameter)? And if so, where would the server state token be returned to the user? As a new property in the StateChange object? Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "Channel Binding Signalling for the Generic Security Services Application Programming Interface", Robbie Harwood, Nico Williams, 2019-02-05, Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different than those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API. "PKINIT Algorithm Agility", Love Astrand, Larry Zhu, Margaret Cullen, Margaret Cullen, Greg Hudson, 2019-04-20, This document updates the Public Key Cryptography for Initial Authentication in Kerberos standard (PKINIT) [RFC4556], to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "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) -------------------------------------------------------- "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", Jim Schaad, Blake Ramsdell, Sean Turner, 2018-09-04, This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. "Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling", Jim Schaad, Blake Ramsdell, Sean Turner, 2018-09-04, This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. "Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs", Panos Kampanakis, Quynh Dang, 2019-04-11, Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs 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-04-11, This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. 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-02-04, 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. "Hash Of Root Key Certificate Extension", Russ Housley, 2019-01-31, This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. "Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, 2019-03-06, This document specifies the conventions for using the the HSS/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 [HASHSIG]. "Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)", Russ Housley, 2019-03-08, 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. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2018-11-29, 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-03-06, 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, 2018-11-04, 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", Vince Fuller, Dino Farinacci, Albert Cabellos-Aparicio, 2019-02-04, 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-04-11, This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2019-03-27, 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, 2018-11-14, 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, 2018-11-13, 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, 2018-11-19, 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-04-11, This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. "Vendor Specific LISP Canonical Address Format (LCAF)", Alberto Rodriguez-Natal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino Farinacci, 2019-04-04, 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, John Lemon, Puneet Agarwal, Darrel Lewis, Michael Smith, 2018-09-20, 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-03-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-02-15, This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocol (LISP) Map-Versioning", which is the initial experimental specifications of the mechanisms updated by this document. "LISP Control-Plane ECDSA Authentication and Authorization", Dino Farinacci, Erik Nordmark, 2019-03-27, 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-02-05, 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 use a flexible header with a variable number of options themselves of a variable length. The CoAP protocol is asymmetric in its format messages, the format of the header packet in the request messages is different than in the response messages. Most of the compression mechanisms have been introduced in [I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how to use the SCHC compression for CoAP. "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP", Ana Minaburo, Laurent Toutain, Carles Gomez, Dominique Barthel, Juan Zuniga, 2018-12-14, 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", Nicolas Sornin, Michael Coracin, Ivaylo Petrov, Alper Yegin, Julien Catalano, Vincent AUDEBERT, 2019-04-19, 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. Link State Routing (lsr) ------------------------ "IS-IS Extensions for Segment Routing", Stefano Previdi, Les Ginsberg, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Bruno Decraene, 2019-04-17, 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-03-07, This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. "YANG Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2019-01-24, 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 (NDMA) as described in RFC 8342. "H-bit Support for OSPFv2", Keyur Patel, Padma Pillay-Esnault, Manish Bhardwaj, Serpil Bayraktar, 2018-08-27, OSPFv3 defines an option bit for router-LSAs known as the R-bit in RFC5340. If the R-bit is clear, an OSPFv3 router can participate in OSPF topology flooding, however it will not be used as a transit router. In such cases, other routers in the OSPFv3 routing domain only install routes to allow local traffic delivery. This document defines the H-bit functionality to prevent other OSPFv2 routers from using the router for transit traffic in OSPFv2 routing domains as described in RFC 2328. This document updates RFC 2328. "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2019-03-07, 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-03-10, 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, 2018-12-10, 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-04-08, Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. 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 (TE) Attribute Reuse", Peter Psenak, Les Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake, 2019-04-11, 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 Traffic Engineering or GMPLS. This document defines how to distribute such attributes in OSPFv2 and OSPFv3 for applications other than MPLS Traffic Engineering or GMPLS. "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils, Ketan Talaulikar, Arkadiy Gulko, 2018-11-12, 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 Prefix-SIDs to steer packets along the constraint- based paths. "Restart Signaling for IS-IS", Les Ginsberg, Paul Wells, 2018-12-13, 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 mechansim 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, 2018-12-04, 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-03-08, 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, Tony Przygienda, Dave Cooper, Luay Jalil, Srinath Dontula, 2019-02-25, 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 Extension for Prefix Originator", Aijun Wang, Acee Lindem, Jie Dong, Ketan Talaulikar, Peter Psenak, 2019-02-28, This document describes OSPFv2 and OSPFv3 encodings to advertise the router-id of the originator of inter-area prefixes for OSPFv2 and OSPFv3 LSAs, which are needed in several use cases in several multi- area OSPF use cases. Link State Vector Routing (lsvr) -------------------------------- "Shortest Path Routing Extensions for BGP Protocol", Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx, 2018-12-20, 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, 2018-10-22, This document discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in the CLOS architecture of Data Center Networks. The document is intended to provide a simplified guide for the deployment of LSVR extensions. "Link State Over Ethernet", Randy Bush, Rob Austein, Keyur Patel, 2019-02-17, Used in Massive Data Centers (MDCs), BGP-SPF and similar protocols need link neighbor discovery, link encapsulation data, and Layer 2 liveness. The Link State Over Ethernet protocol provides link discovery, exchanges supported encapsulations (IPv4, IPv6, ...), discovers encapsulation addresses (Layer 3 / MPLS identifiers) over raw Ethernet, and provides layer 2 liveness checking. The interface data are pushed directly to a BGP API (for LSVR), obviating the need for centralized topology distribution architectures. This protocol is intended to be more widely applicable to other upper layer routing protocols which need link discovery and characterisation. 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. "Neighbor Management Policy for 6LoWPAN", Rahul Jadhav, Rabi Sahoo, Simon Duquennoy, Joakim Eriksson, 2019-02-21, This document describes the problems associated with neighbor cache management in multihop networks involving resource-constrained devices. Thereafter, it also presents a sample neighbor management policy that allows efficient cache management in multihop LLNs (low- power and lossy networks such as LoWPAN) with resource-constrained devices. "TCP Usage Guidance in the Internet of Things (IoT)", Carles Gomez, Jon Crowcroft, Michael Scharf, 2019-03-29, This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. "Comparison of CoAP Security Protocols", John Mattsson, Francesca Palombini, 2019-03-11, This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN-GHC compression. DTLS is analyzed with and without Connection ID. "Virtual reassembly buffers in 6LoWPAN", Carsten Bormann, Thomas Watteyne, 2019-03-11, When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it. This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature. The present document attempts to fill that gap. "Alternative Elliptic Curve Representations", Rene Struik, 2019-04-19, 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. "Minimal ESP", Daniel Migault, Tobias Guggemos, 2019-04-07, This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. A minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP, but instead to enable a limited implementation to interoperate with implementations of RFC 4303 ESP. This document describes what is required from RFC 4303 ESP as well as various ways to optimize compliance with RFC 4303 ESP. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP Control Plane Based Pause Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2019-04-03, This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. "DLEP Multi-Hop Forwarding Extension", Bow-Nan Cheng, Lou Berger, 2019-03-11, This document defines an extension to the DLEP protocol that enables the reporting and control of Multi-Hop Forwarding by DLEP capable modems. "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 DiffServ Aware Credit Window Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2019-03-06, This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. "DLEP Link Identifier Extension", Rick Taylor, Stan Ratliff, 2018-08-23, There exists a class of modems that would benefit from supporting the Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a single Layer 2 network domain as required by DLEP. Such devices may be: o Modems that maintain a varying link to some upstream backbone network infrastructure, where the ability to announce link state and DLEP metrics is desired, but the concept of a DLEP destination router for the backbone does not apply. Examples of such devices can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, and some satellite terminals. o Modems that provide Layer 3 wide area network connectivity between devices, where remote DLEP destinations do exist, but are not directly reachable by MAC address, such as modems that contain embedded routing functionality. This document introduces an optional extension to the core DLEP specification, allowing DLEP to be used between routers and modems that operate in this way. Note: o This document is intended as an extension to the core DLEP specification, and readers are expected to be fully conversant with the operation of core DLEP. "DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng, David Wiggins, Lou Berger, Stan Ratliff, 2019-03-06, This document defines new DLEP protocol Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are defined in an extensible and reusable fashion. Their use will be mandated in other documents defining specific DLEP extensions. "DLEP Traffic Classification Data Item", Bow-Nan Cheng, David Wiggins, Lou Berger, 2019-03-06, This document defines a new DLEP protocol Data Item that is used to support traffic classification. Traffic classification information is used to identify traffic flows based on frame/packet content such as destination address. The Data Item is defined in an extensible and reusable fashion. It's use will be mandated in other documents defining specific DLEP extensions. This document aloas introduces DLEP sub data items, and sub data items are defined to support DiffServ and Ethernet traffic classification. MBONE Deployment (mboned) ------------------------- "Multicast in the Data Center Overview", Mike McBride, Olufemi Komolafe, 2019-03-11, 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-04-15, 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 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 performace of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices. "Multicast YANG Data Model", Zheng(Sandy) Zhang, Cui(Linda) Wang, Ying Cheng, Xufeng Liu, Mahesh Sivakumar, 2019-02-27, 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-02-11, 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-04-04, 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) -------------------------------------------- "Using XMPP for Security Information Exchange", Nancy Cam-Winget, Syam Appala, Scott Pope, Peter Saint-Andre, 2019-03-27, This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF). "CBOR/JSON binding of IODEF", Takeshi Takahashi, Roman Danyliw, Mio Suzuki, 2019-04-01, RFC7970 specified an information model and a corresponding XML data model for exchanging incident and indicator information. This draft provides an alternative data model implementation in CBOR/JSON. "Definition of ROLIE CSIRT Extension", Stephen Banghart, John Field, 2019-03-26, 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-03-28, 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 and the draft Vulnerability Description Ontology (VDO) [vdo] are discussed. Messaging Layer Security (mls) ------------------------------ "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert, 2019-03-22, Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. "The Messaging Layer Security (MLS) Architecture", Emad Omara, Benjamin Beurdouche, Eric Rescorla, Srinivas Inguva, Albert Kwon, Alan Duric, 2019-03-11, 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. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", Ali Begen, Paul Kyzivat, Colin Perkins, Mark Handley, 2019-03-21, 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, Ari Keranen, 2018-11-09, This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. "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-03-21, 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-04-21, 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-01-03, 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. Simple mitigation techniques are defined for each. Multiprotocol Label Switching (mpls) ------------------------------------ "Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces", Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, Mach Chen, 2019-04-04, This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. This document updates RFC8029. "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-04-03, 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-01-11, This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. "A YANG Data Model for MPLS Base", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, 2019-02-24, This document contains a specification of the 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-03-08, 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, Ina Minei, Dante Pacella, Tarek Saad, 2019-02-08, RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the LSP related states along the reserved path. In the absence of refresh messages, the LSP related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP- TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale. RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in RFC 2205. However, the protocol extensions defined in RFC 4090 for supporting fast reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states. In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. Coupling LSP state with the corresponding RSVP-TE signaling adjacencies as recommended in RFC 8370 will apply in scenarios other than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC 4090 FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in scenarios not covered by procedures defined in RSVP-TE Scaling Recommendations. Hence, this document updates the procedures defined in RFC 4090 to support Refresh-Interval Independent RSVP (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, 2018-10-22, 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, 2018-10-22, 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, 2018-12-12, 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, 2018-12-12, 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 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, 2018-11-03, 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. "Signaling RSVP-TE tunnels on a shared MPLS forwarding plane", Harish Sitaraman, Vishnu Beeram, Tejal Parikh, Tarek Saad, 2019-01-31, As the scale of MPLS RSVP-TE networks has grown, so the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in control plane state. However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane. This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control plane scaling on that node. It introduces the notion of pre-installed 'per Traffic Engineering (TE) link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. "MPLS Egress Protection Framework", Yimin Shen, Jeyananth Jeganathan, Bruno Decraene, Hannes Gredler, Carsten Michel, Huaimo Chen, Yuanlong Jiang, 2019-01-02, This document specifies a fast reroute framework for protecting IP/ MPLS services and MPLS transport tunnels against egress node and egress link failures. In this framework, the penultimate-hop router of an MPLS tunnel acts as the point of local repair (PLR) for an egress node failure, and the egress router of the MPLS tunnel acts as the PLR for an egress link failure. Each of them pre-establishes a bypass tunnel to a protector. Upon an egress node or link failure, the corresponding PLR performs local failure detection and local repair, by rerouting packets over the corresponding bypass tunnel. The protector in turn performs context label switching or context IP forwarding to send the packets to the ultimate service destination(s). This mechanism can be used to reduce traffic loss before global repair reacts to the failure and control plane protocols converge on the topology changes due to the failure. The framework is applicable to all types of IP/MPLS services and MPLS tunnels. Under the framework, service protocol extensions may be further specified to support service label distribution from an egress router to a protector. "An MPLS-Based Forwarding Plane for Service Function Chaining", Adrian Farrel, Stewart Bryant, John Drake, 2019-03-07, This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. "SR-MPLS over IP", Xiaohu Xu, Stewart Bryant, Adrian Farrel, Syed Hassan, Wim Henderickx, Zhenbin Li, 2019-04-13, 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, 2018-11-04, 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. "MPLS Transport Encapsulation For The SFC NSH", Andrew Malis, Stewart Bryant, Joel Halpern, Wim Henderickx, 2019-03-24, This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. "RFC8287 Sub-TLV Length Clarification", Nagendra Kumar, Carlos Pignataro, Faisal Iqbal, Sasha Vainshtein, 2019-03-25, 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. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch, 2019-02-17, 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) ------------------------------- "Secure Zero Touch Provisioning (SZTP)", Kent Watsen, Mikael Abrahamsson, Ian Farrer, 2019-01-15, This draft presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enables it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. "Subscription to YANG Datastores", Alexander Clemm, Eric Voit, Alberto Prieto, Ambika Tripathy, Einar Nilsen-Nygaard, Andy Bierman, Balazs Lengyel, 2019-02-04, Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu, Liang Xia, 2019-04-07, 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-04-07, 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-04-07" --> 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-04-07, 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-04-07, 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-04-07" --> 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 NETCONF", Eric Voit, Alexander Clemm, Alberto Prieto, Einar Nilsen-Nygaard, Ambika Tripathy, 2019-02-13, This document provides a NETCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. "Dynamic subscription to YANG Events and Datastores over RESTCONF", Eric Voit, Reshad Rahman, Einar Nilsen-Nygaard, Alexander Clemm, Andy Bierman, 2019-02-14, This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. "YANG Data Model for a Centralized Keystore Mechanism", Kent Watsen, 2019-03-09, This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of asymmetric keys and their associated certificates, and notification for when configured certificates are about to expire. "Subscription to YANG Event Notifications", Eric Voit, Alexander Clemm, Alberto Prieto, Einar Nilsen-Nygaard, Ambika Tripathy, 2019-02-13, This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. "UDP based Publication Channel for Streaming Telemetry", Guangying Zheng, Tianran Zhou, Alexander Clemm, 2019-03-11, This document describes a UDP-based publication channel for streaming telemetry use to collect data from devices. A new shim header is proposed to facilitate the distributed data collection mechanism which directly pushes data from line cards to the collector. Because of the lightweight UDP encapsulation, higher frequency and better transit performance can be achieved. "Notification Message Headers and Bundles", Eric Voit, Henk Birkholz, Andy Bierman, Alexander Clemm, Tim Jenkins, 2019-02-15, This document defines a new notification message format, using yang- data. 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-03-09, This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. "YANG Data Model for Global Trust Anchors", Kent Watsen, 2019-03-09, 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-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log "YangPush Notification Capabilities", Balazs Lengyel, Alexander Clemm, 2019-03-01, This document proposes a YANG module that allows a YANG server to specify server capabilities related to "Subscription to YANG Datastores" (YangPush). It proposes to use YANG Instance Data to document this information already in implementation time. Network Modeling (netmod) ------------------------- "A YANG Data Model for Syslog Configuration", Clyde Wildes, Kiran Koushik, 2018-03-16, This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. "Common Interface Extension YANG Data Models", Robert Wilton, David Ball, tsingh@juniper.net, Selvakumar Sivaraj, 2019-03-05, This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "Sub-interface VLAN YANG Data Models", Robert Wilton, David Ball, tapsingh@cisco.com, Selvakumar Sivaraj, 2019-03-06, This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orginating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. "YANG Data Structure Extensions", Andy Bierman, Martin Bjorklund, Kent Watsen, 2019-04-15, This document describes YANG mechanisms for defining abstract data structures with YANG. "YANG Module Tags", Christian Hopps, Lou Berger, Dean Bogdanovic, 2019-03-09, 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 standardized 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, 2018-10-22, 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-04-06, This document defines a simple and yet time-proven strategy for handling long lines in inclusions in internet drafts and RFCs using a backslash ('\') character to indicate where line-folding has occurred. The strategy works on any text-based content, but is primarily intended for a structured sequence of lines rather than for two-dimensional imagery. The approach produces consistent results, regardless of the content, that is both self-documenting and enables automated reconstitution of the original content. "YANG Instance Data File Format", Balazs Lengyel, Benoit Claise, 2019-02-26, There is a need to document data defined in YANG models when a live YANG 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 YANG 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-03-26, 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-04-15, This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6991. Internet Video Codec (netvc) ---------------------------- "