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 2018-03-04 04:05:28 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, 2018-01-08, Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. 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, 2018-02-23, This specification proposes proxy operations for IPv6 Neighbor Discovery on behalf of devices located on broadcast-inefficient wireless networks. A broadcast-efficient backbone running classical IPv6 Neighbor Discovery federates multiple wireless links to form a large MultiLink Subnet, but the broadcast domain does not need to extend to the wireless links for the purpose of ND operation. Backbone Routers placed at the wireless edge of the backbone proxy the ND operation and route packets from/to registered nodes, and wireless nodes register or are proxy-registered to the Backbone Router to setup proxy services in a fashion that is essentially similar to a classical Layer-2 association. "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", Carles Gomez, Seyed Darroudi, Teemu Savolainen, 2017-09-11, 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 the mechanisms needed to enable IPv6 over mesh networks composed of Bluetooth low energy links established by using the Bluetooth Internet Protocol Support Profile. "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Pascal Thubert, Behcet Sarikaya, Mohit Sethi, 2018-02-23, This document defines an extension to 6LoWPAN Neighbor Discovery (ND) [RFC6775][I-D.ietf-6lo-rfc6775-update] called Address Protected ND (AP-ND); AP-ND protects the owner of an address against address theft and impersonation inside a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic Owner Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID uniquely identifies the owner of the Registered Address and can be used for proof-of-ownership. It is used in 6LoWPAN ND in place of the EUI-64-based unique ID that is associated with the registration. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the anchor state information of the Registered Address, and Source Address Validation can be enforced. "IPv6 over Constrained Node Networks (6lo) Applicability & Use cases", Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita Chakrabarti, 2017-10-30, 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 link layer networks connecting devices to each other or to each cloud. "Registration Extensions for 6LoWPAN Neighbor Discovery", Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins, 2018-02-23, This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network. "Packet Delivery Deadline time in 6LoWPAN Routing Header", Lijo Thomas, P.M. Akshay, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins, 2017-11-14, This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. IPv6 Maintenance (6man) ----------------------- "IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils, Kamran Raza, Darren Dukes, John Leddy, Brian Field, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Satoru Matsushima, Ida Leung, J. Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk, 2018-01-20, Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. "IPv6 Node Requirements", Tim Chown, John Loughney, Timothy Winters, 2018-02-27, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. "IPv6 ND PIO Flags IANA considerations", Ole Troan, 2018-01-10, The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. This document updates RFC 4861. 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, 2017-11-29, This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications. "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2018-03-02, This document provides a glossary of terminology used in IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH). This document extends existing terminology documents for Low-power and Lossy Networks. "6top Protocol (6P)", Qin Wang, Xavier Vilajosana, Thomas Watteyne, 2017-10-25, This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6P layer is formed by the 6top Protocol defined in this document and 6top Scheduling Function(s). A 6top Scheduling Function (SF) decides when to add/ delete cells, and triggers 6P Transactions. This document lists the requirements for an SF, but leaves the definition of SFs out of scope. "Minimal Security Framework for 6TiSCH", Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson, 2017-10-30, This document describes the minimal configuration required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The entities involved use CoAP (Constrained Application Protocol) and OSCORE (Object Security for Constrained RESTful Environments). The configuration 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. The result of the joining process is that the JRC configures the pledge with link-layer keying material and a short link-layer address. This specification also defines a new Stateless-Proxy CoAP option. Additional security mechanisms may be added on top of this minimal framework. "6tisch Zero-Touch Secure Join protocol", Michael Richardson, Benjamin Damm, 2017-10-30, This document describes a zero-touch 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 her is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. "6TiSCH 6top Scheduling Function Zero / Experimental (SFX)", Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura, 2017-09-25, This document defines a Scheduling Function called "Scheduling Function Zero" (SF0) in its Experimental version. SF0 dynamically adapts the number of scheduled cells between neighbor nodes, based on the amount of currently allocated cells and the neighbor nodes' cell requirements. Neighbor nodes negotiate in a distributed neighbor-to- neighbor basis the number of cell(s) to be added/deleted. SF0 uses the 6P signaling messages to add/delete cells in the schedule. This function selects the candidate cells from the schedule, defines which cells will be added/deleted and triggers the allocation/deallocation process. "6TiSCH Minimal Scheduling Function (MSF)", Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, 2018-03-02, This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6top 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, 2017-11-13, 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)", Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2018-02-13, This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. 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. "CBOR Web Token (CWT)", Michael Jones, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2018-02-02, CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. "Datagram Transport Layer Security (DTLS) Profiles for Authentication and Authorization for Constrained Environments (ACE)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz, 2017-10-30, This specification defines two profiles for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. 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 node 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, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2018-03-03, 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", Ludwig Seitz, Francesca Palombini, Martin Gunnarsson, 2017-12-12, 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, Sandeep Kumar, Michael Richardson, Martin Furuhed, Shahid Raza, 2018-02-28, Enrollment over Secure Transport (EST) [RFC7030] is used as a certificate management protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST- coaps). This allows low-resource constrained devices to re-use existing EST functionality. Example low-resource use cases for EST are: secure bootstrapping and certificate enrollment. Automated Certificate Management Environment (acme) --------------------------------------------------- "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, Daniel McCarney, James Kasten, 2017-12-14, Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). "CAA Record Extensions for Account URI and ACME Method Binding", Hugo Landau, 2017-08-30, 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, 2018-03-03, Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. 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) certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. "Extensions to Automatic Certificate Management Environment for email TLS", Alexey Melnikov, 2017-11-12, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services. "Extensions to Automatic Certificate Management Environment for end user S/MIME certificates", Alexey Melnikov, 2017-10-29, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME. "ACME Identifiers and Challenges for VoIP Service Providers", Mary Barnes, Chris Wendt, 2017-10-30, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for VoIP service providers to support Secure Telephony Identity (STI). "ACME Identifiers and Challenges for Telephone Numbers", Jon Peterson, Richard Barnes, 2017-10-30, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificate for telephonoe numbers. "ACME IP Identifier Validation Extension", Roland Shoemaker, 2017-09-18, 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-03-02, This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol which allows for domain control validation using TLS. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, Shiwei Chen, 2018-03-01, 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 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 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 server can send just the changes. "ALTO Cost Calendar", Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan, 2017-12-08, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information in order to allow applications to make network informed decisions. The present draft extends the ALTO cost information so as to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that need to schedule their data transfers and connections and have a degree of freedom to do so. ALTO guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. Besides, the ALTO Cost Calendar allows to schedule the ALTO requests themselves and thus to save a number of ALTO transactions. This draft proposes new capabilities and attributes on filtered cost maps and endpoint cost maps enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to ALTO metrics with time-varying values. With ALTO Cost Calendars, 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 IRD and ALTO Server responses. "ALTO Performance Cost Metrics", Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2017-12-22, 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 [ALTO] has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). 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. "ALTO Extension: Path Vector Cost Type", Greg Bernstein, Shiwei Chen, Kai Gao, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, J. Zhang, 2017-12-18, The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] has defined several resources and services to provide clients with basic network information. However, the base ALTO protocol and latest extensions only provide end-to-end metrics, 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 capacity regions for a given set of flows. A non-normative example called multi-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, 2017-07-20, The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect 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 componet that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application Layer Traffic Optimization (ALTO) protocol. "Unified Properties for the ALTO Protocol", Wendy Roome, Shiwei Chen, Sabine Randriamasy, Yang Yang, J. Zhang, 2018-03-01, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to other entity domains, 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, 2017-12-17, 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 OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not misconfigured. "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen, 2018-02-20, This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) 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-02-23, This document describes a reference model for Autonomic Networking. 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. "Using Autonomic Control Plane for Stable Connectivity of Network OAM", Toerless Eckert, Michael Behringer, 2018-02-05, OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong, 2017-11-24, This document is a conceptual outline of the application programming interface (API) of 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. "Voucher Profile for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, 2018-01-24, This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a CMS structure. Other YANG- derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong, 2018-03-03, 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. Applications and Real-Time Area (art) ------------------------------------- "A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)", Roozbeh Atarius, 2018-01-13, This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal encoded digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. "Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID", Roozbeh Atarius, 2018-01-13, This specification specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior. "Representing DNS Messages in JSON", Paul Hoffman, 2017-10-21, Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search those without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of this document can be described in other documents for specific applications and usage scenarios. "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. "E-mail Authentication for Internationalized Mail", John Levine, 2018-02-08, SPF, DKIM, and DMARC 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. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification clarifies when to use which form of domain names when using SPF, DKIM, and DMARC and when creating Authentication- Results headers. "Scheme Specification for the pwid URI", Eld Zierau, 2017-12-08, This document specifies a Uniform Resource Identifier (URI) for Persistent Web IDentifiers to web material in web archives using the 'pwid' scheme name. The purpose of the standard is to support general, global, sustainable, humanly readable, technology agnostic, persistent and precise web references for web materials. The PWID URI can assist in two ways: First, by providing potential resolvable precise and persistent reference scheme for documents, which is not sufficiently covered by existing web reference practices. Second, by providing a standardized way to specify web elements in a web collection also known as web corpus. Definitions of web collections are often needed for extraction of data used in production of research results, e.g. for evaluations in the future. Current practices today are not persistent as they often use some CDX version, which vary for different implementations. "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", John Klensin, Asmus Freytag, 2017-09-12, The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFC 5980 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. "Resolving Multiple Time Scales in the Internet", Joseph Touch, 2018-01-19, Internet systems use a variety of time scales, which can complicate time comparisons and calculations. This document explains these various ways of indicating time and explains how they can be used together safely. This document is intended as a companion to Internet time as discussed in RFC 3339. "Zstandard Compression and The application/zstd Media Type", Yann Collet, Murray Kucherawy, 2017-11-12, Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism, and registers a media type to be used when transporting zstd-compressed via Multipurpose Internet Mail Extensions (MIME). "Defining Well-Known Uniform Resource Identifiers (URIs)", Mark Nottingham, 2018-02-14, This memo defines a path prefix for "well-known locations", "/.well- known/", in selected Uniform Resource Identifier (URI) schemes. "Iris.arpa is Deprecated", Ted Hardie, 2018-01-10, This document requests that iris.arpa and areg.iris.arpa be removed from the arpa zone. "The Archive and Package (arcp) URI scheme", Stian Soiland-Reyes, Marcos Caceres, 2018-02-05, This specification define the Archive and Package URI scheme "arcp". arcp URIs can be used to consume or reference hypermedia resources bundled inside a file archive or an application package, as well as to resolve URIs for archive resources within a programmatic framework. This URI scheme provides mechanisms to generate a unique base URI to represent the root of the archive, so that relative URI references in a bundled resource can be resolved within the archive without having to extract the archive content on the local file system. An arcp URI can be used for purposes of isolation (e.g. when consuming multiple archives), security constraints (avoiding "climb out" from the archive), or for externally identiyfing sub-resources referenced by hypermedia formats. 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, Hui Zheng, 2017-10-30, 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, 2017-10-30, 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, 2017-10-30, This document describes a feedback message intended to enable congestion control for interactive real-time traffic. The RTP Media Congestion Avoidance Techniques (RMCAT) Working Group formed a design team to analyze feedback requirements from various congestion control algorithms and to design a generic feedback message to help ensure interoperability across those algorithms. The feedback message is designed for a sender-based congestion control, which means the receiver of the media will send necessary feedback to the sender of the media to perform the congestion control at the sender. 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) ------------------------------ "The Babel Routing Protocol", Juliusz Chroboczek, David Schinazi, 2017-10-29, Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. "Babel Information Model", Barbara Stark, 2018-01-02, This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as netconf) to report on its current state and may allow some limited configuration of protocol constants. "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz Chroboczek, 2018-01-31, 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. BGP Enabled ServiceS (bess) --------------------------- "L2L3 VPN Multicast MIB", Zhaohui Zhang, Hiroshi Tsunoda, 2018-02-27, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast. "BGP/MPLS Layer 3 VPN Multicast Management Information Base", Zhaohui Zhang, Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain, Hiroshi Tsunoda, 2017-12-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor MVPN, Multicast in MultiProtocol Label Switching/Border Gateway Protocol (MPLS/BGP) IP Virtual Private Networks (VPNs) on a Provider Edge router. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Ali Sajassi, Jim Uttaro, 2018-02-24, This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained on the example scenario, analyzing the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. "A Network Virtualization Overlay Solution using EVPN", Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx, 2018-02-09, This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over Generic Routing Encapsulation (GRE). This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE) encapsulation; however, some incremental work is required which will be covered in a separate document. This document also specifies new multi-homing procedures for split-horizon filtering and mass-withdraw. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Boundary Router (ASBR) procedures for multi-homing of Network Virtualization (NV) Edge devices. "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-02-27, EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based 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, 2018-02-14, This draft discusses the backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2017-10-24, Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), i.e., a single IP subnet, to be distributed over multiple sites. The sites 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 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. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2018-03-02, This draft defines protocol extensions required to synchronize flow label states among Provider Edges PE(s) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer2 Virtual Private Networks (L2VPNs). This draft updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2018-02-16, This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. "Optimized Ingress Replication solution for EVPN", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, Aldrin Isaac, Mukul Katiyar, 2018-02-23, Network Virtualization Overlay (NVO) networks using EVPN as control plane may use ingress replication (IR) or PIM-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, 2017-10-04, The MAC/IP Advertisement route specified in [RFC7432] 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, as explained in [RFC6820]. This document describes how the [RFC7432] 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. "A new Designated Forwarder Election for the EVPN", satyamoh@cisco.com, Keyur Patel, Ali Sajassi, John Drake, Tony Przygienda, 2017-10-10, This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN "Service Chaining using Virtual Networks with BGP VPNs", Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin, 2018-02-12, 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. "Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang, 2018-02-26, The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, and 7524. "Yang Data Model for EVPN", Patrice Brissette, Himanshu Shah, Iftekhar Hussain, Kishore Tiruveedhula, Jorge Rabadan, 2018-02-21, 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-Wher Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula, 2018-02-18, 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. "Yang Data Model for BGP/MPLS L3 VPNs", Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen, 2017-10-18, This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs. "AC-Influenced Designated Forwarder Election for EVPN", Jorge Rabadan, Kiran Nagaraj, Senthil Sathappan, Vinod Prabhu, Autumn Liu, Wen Lin, 2018-01-18, The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. While PE node or link failures trigger the DF re-election for a given , individual Attachment Circuit (AC) or MAC-VRF failures do not trigger such DF re-election and the traffic may therefore be permanently impacted, even though there is an alternative path. This document improves the DF election algorithm so that the AC status can influence the result of the election and this type of "logical" failures can be protected too. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2017-09-19, 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, 2017-10-30, 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. This document adopts the SFC architecture described in RFC 7665. "PIM Proxy in EVPN Networks", Jorge Rabadan, Jayant Kotalwar, Senthil Sathappan, Zhaohui Zhang, Ali Sajassi, 2017-10-30, Ethernet Virtual Private Networks [RFC7432] are becoming prevalent in Data Centers, Data Center Interconnect (DCI) and Service Provider VPN applications. One of the goals that EVPN pursues is the reduction of flooding and the efficiency of CE-based control plane procedures in Broadcast Domains. Examples of this are Proxy ARP/ND and IGMP/MLD Proxy. This document complements the latter, describing the procedures required to minimize the flooding of PIM messages in EVPN Broadcast Domains, and optimize the IP Multicast delivery between PIM routers. "MVPN and MSDP SA Interoperation", Zhaohui Zhang, Leonard Giuliano, 2018-01-18, 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. "Propagation of IPv6 Neighbor Advertisement Flags in EVPN", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, 2017-10-04, The MAC/IP Advertisement route specified in [RFC7432] 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 and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements. "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", John Drake, Adrian Farrel, Eric Rosen, Keyur Patel, Luay Jalil, 2017-10-27, Data centers have become 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 operating 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, 2018-02-13, Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), i.e., a single IP subnet, to be distributed over multiple sites. The sites 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 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. 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, Paul Jones, 2017-10-30, 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 15. "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) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, Gregory Mirsky, 2018-02-21, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. "BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks, Gregory Mirsky, 2018-02-21, This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Juniper Networks, Gregory Mirsky, 2018-03-01, 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, 2017-11-21, 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, 2017-11-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, 2017-11-21, 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-01-24, This document describes use of Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay network. Bit Indexed Explicit Replication (bier) --------------------------------------- "OSPF Extensions for BIER", Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Zhaohui Zhang, Sam Aldrin, 2018-02-23, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits set in BIER packet header. This document describes the OSPF [RFC2328] protocol extension required for BIER with MPLS encapsulation [RFC8296]. Support for other encapsulation types is outside thescope of this document. The use of multiple encapsulation types is outside the scope of this document. "Multicast VPN Using BIER", Eric Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, Tony Przygienda, 2018-02-22, The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network. "BIER Use Cases", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya, Caitlin Bestler, 2018-01-16, 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. "BIER support via ISIS", Les Ginsberg, Tony Przygienda, Sam Aldrin, Zhaohui Zhang, 2018-02-23, This document defines ISIS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture. "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, 2018-03-03, 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, 2018-01-17, 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-01-17, 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, 2017-10-03, 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-01-22, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2018-02-06, This document defines a YANG data model for BIER configuration and operation. "BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, 2018-02-08, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 2017-08-15, This document specifies protocols and procedures for forwarding broadcast, unknown unicast and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). "Traffic Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth, 2018-01-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, IJsbrand Wijnands, mankamana mishra, 2018-02-23, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for PIM Joins and Prunes to be signaled through a BIER core. Allowing PIM routers to run traditional PIM multicast services through a BIER core. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2018-02-25, This document defines terminology for benchmarking an SDN controller's control plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN controllers. The terms provided in this document help to benchmark SDN controller's performance independent of the controller's supported protocols and/or network services. A mechanism for benchmarking the performance of SDN controllers is defined in the companion methodology document I-D sdn-controller-benchmark-meth. These two documents provide a standard mechanism to measure and evaluate the performance of various controller implementations. "Benchmarking Methodology for SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2018-02-25, This document defines the methodologies for benchmarking control plane performance of SDN controllers. SDN controller is a core component in software-defined networking architecture that controls the network behavior. Terminology related to benchmarking SDN controllers is described in the companion terminology documentI-D sdn-controller-benchmark-term. SDN controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors have taken the approach of considering an SDN controller as a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. The intent of this document is to provide a standard mechanism to measure the performance of all controller implementations. "Benchmarking Methodology for EVPN and PBB-EVPN", Kishore Tiruveedhula, sudhin jacob, 2018-02-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. This document specifically covers methodologies for benchmarking EVPN/PBB-EVPN convergence, data plane performance, control plane performance. Calendaring Extensions (calext) ------------------------------- "Support for iCalendar Relationships", Michael Douglass, 2017-10-11, This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. "Event Publishing Extensions to iCalendar", Michael Douglass, 2017-10-11, This specification introduces 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, 2017-07-24, 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 non-standard method of updating an existing resource via HTTP. "JSCalendar: A JSON representation of calendar data", Neil Jenkins, Robert Stepanek, 2018-03-02, 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. Captive Portal Interaction (capport) ------------------------------------ "CAPPORT Architecture", Kyle Larose, David Dolson, 2017-09-29, This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, ICMP, 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, 2018-02-04, This document describes an HTTP API that allows hosts to interact with a Captive Portal system. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Concise Binary Object Representation (CBOR)", Carsten Bormann, Paul Hoffman, 2018-03-02, 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 data structures", Henk Birkholz, Christoph Vigano, Carsten Bormann, 2018-02-26, This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Information Encoding for WSON with Impairments Validation", Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Young Lee, Fatai Zhang, 2018-02-20, 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. "GMPLS OSPF-TE Extensions in support of Flexi-grid DWDM networks", Xian Zhang, zhenghaomian@huawei.com, Ramon Casellas, Oscar de Dios, Daniele Ceccarelli, 2017-02-16, The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as flexi-grid. Based on the characteristics of flexi-grid defined in G.694.1, RFC 7698 and 7699, this document describes the OSPF-TE extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. "Ethernet Traffic Parameters with Availability Information", Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2018-01-29, 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. Availability is typically used for describing the link during 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 Label Switched Path (LSP) in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth. "A framework for Management and Control of DWDM optical interface parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, Julien Meuric, 2017-12-15, 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 EMS, NMS or 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 Optical Networks", Young Lee, Dhruv Dhody, Xian Zhang, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, Ricard Vilata, 2018-02-27, This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in wavelength switched optical networks (WSONs). "A framework for Management and Control of microwave and millimeter wave interface parameters", Jonas Ahlberg, Min Ye, Xi Li, Luis Contreras, Carlos Bernardos, 2018-01-04, The unification of control and management of microwave radio link interfaces is a precondition for seamless multilayer networking and automated network provisioning and operation. This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG Data Model. The purpose is to create a framework for identification of the necessary information elements and definition of a YANG Data Model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic which could also be used by other technologies. "A YANG Data Model for Microwave Radio Link", Jonas Ahlberg, Min Ye, Xi Li, Daniela Spreafico, Marko Vaupotic, 2018-03-03, 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. "A YANG Data Model for Optical Transport Network Topology", zhenghaomian@huawei.com, Zheyu Fan, Anurag Sharma, Xufeng Liu, Sergio Belotti, Yunbin Xu, Lei Wang, Oscar de Dios, 2017-10-30, A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic transparently across the server-layer network resources. A transport network can be constructed from equipments utilizing any of a number of different transport technologies such as the evolving Optical Transport Networks (OTN) or packet transport as provided by the MPLS-Transport Profile (MPLS-TP). 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 via a REST interface, for OTN topology related operations such as obtaining the relevant topology resource information. "OTN Tunnel YANG Model", zhenghaomian@huawei.com, Zheyu Fan, Anurag Sharma, Rajan Rao, Sergio Belotti, Victor Lopezalvarez, Yunbo Li, Yunbin Xu, 2017-10-30, This document describes the YANG data model for OTN Tunnels. "YANG Alarm Module", Stefan Vallin, Martin Bjorklund, 2018-02-08, 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 RPCs 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, 2018-02-09, This document defines a YANG model for managing flexi-grid optical Networks. The model described in this document defines a flexi-grid traffic engineering database. A complementary module is referenced to detail the flexi-grid media channels. This module is grounded on other defined YANG abstract models. "A Yang Data Model for WSON Tunnel", Young Lee, Dhruv Dhody, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, Ricard Vilata, 2018-02-09, This document provides a YANG data model for WSON TE tunnel. "Transport Northbound Interface Applicability Statement and Use Cases", Italo Busi, Daniel King, 2018-02-26, 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 describes the key use cases and requirements to be used as the basis for applicability statements analyzing how IETF data models can be used for transport network control and management. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, Phil Sorber, 2017-10-30, 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) [RFC7519] 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. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "Extensible Binary Meta Language", Steve Lhomme, Dave Rice, Moritz Bunkus, 2018-01-03, 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. "FF Video Codec 1", Michael Niedermayer, Dave Rice, Jerome Martinez, 2018-01-26, 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. Crypto Forum (cfrg) ------------------- "Hash-Based Signatures", David McGrew, Michael Curcio, Scott Fluhrer, 2018-02-26, 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. "Augmented Password-Authenticated Key Exchange (AugPAKE)", SeongHan Shin, Kazukuni Kobara, 2018-01-18, This document describes a secure and highly-efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user's password is chosen from a small set of dictionary, making the password susceptible to offline dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and offline dictionary attacks (on the obtained messages with passive/active attacks). Also, this protocol provides resistance to server compromise in the context that an attacker, who obtained the password verifier from the server, must at least perform offline dictionary attacks to gain any advantage in impersonating the user. The AugPAKE protocol is not only provably secure in the random oracle model but also the most efficient over the previous augmented PAKE protocols (SRP and AMP). "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2018-02-16, This document describes SPAKE2, a means for two parties that share a password to derive a strong shared key with no risk of disclosing the password. This method is compatible with any group, is computationally efficient, and has a strong security proof. "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Joost Rijneveld, Aziz Mohaisen, 2018-01-10, This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand so far known attacks using quantum computers. "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2017-08-03, 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. "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", Shay Gueron, Adam Langley, Yehuda Lindell, 2018-02-10, This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated. "ChaCha20 and Poly1305 for IETF Protocols", Yoav Nir, Adam Langley, 2017-09-16, This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. "Re-keying Mechanisms for Symmetric Keys", Stanislav Smyshlyaev, 2018-02-28, 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. "The Transition from Classical to Post-Quantum Cryptography", Paul Hoffman, 2018-02-12, Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible. "Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin, Dimitrios Papadopoulos, Jan Vcelak, 2017-09-13, 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). 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, 2016-08-09, 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. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)", Robert Hansen, Paul Kyzivat, Lennard Xiao, Christian Groves, 2017-11-20, 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. "CLUE protocol", Roberta Presta, Simon Romano, 2017-10-06, 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. Internet Wideband Audio Codec (codec) ------------------------------------- "Ambisonics in an Ogg Opus Container", Jan Skoglund, Michael Graczyk, 2017-10-30, This document defines an extension to the Opus audio codec to encapsulate coded ambisonics using the Ogg format. Constrained RESTful Environments (core) --------------------------------------- "Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR", Kepeng Li, Akbar Rahman, Carsten Bormann, 2018-02-26, JavaScript Object Notation, JSON (RFC 8259) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC 8288) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC 6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, Christian Amsuess, 2018-03-01, In many M2M 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 hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. "Reusable Interface Definitions for Constrained RESTful Environments", Zach Shelby, Matthieu Vial, Michael Koster, Christian Groves, Julian Zhu, Bill Silverajan, 2017-09-16, 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 the concept of function sets to specify this set of interfaces and resources. Editor's notes: o The git repository for the draft is found at https://github.com/ "Media Types for Sensor Measurement Lists (SenML)", Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keranen, Carsten Bormann, 2018-03-02, This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. "CBOR Encoding of Data Modeled with YANG", Michel Veillette, Alexander Pelov, Abhinav Somaraju, Randy Turner, Ana Minaburo, 2018-02-07, 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, Julian Zhu, Bill Silverajan, 2017-09-15, For CoAP [RFC7252] Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. This specification defines conditional observation attributes that work with Link Bindings or with CoAP Observe [RFC7641]. Editor's note: o 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, 2018-01-22, 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. "CoAP Simple Congestion Control/Advanced", Carsten Bormann, August Betzler, Carles Gomez, Ilker Demirkol, 2018-02-21, CoAP, the Constrained Application Protocol, needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines more advanced, but still simple CoRE Congestion Control mechanisms, called CoCoA. The core of these mechanisms is a Retransmission TimeOut (RTO) algorithm that makes use of Round-Trip Time (RTT) estimates, in contrast with how the RTO is determined as per the base CoAP specification (RFC 7252). The mechanisms defined in this document have relatively low complexity, yet they improve the default CoAP RTO algorithm. The design of the mechanisms in this specification has made use of input from simulations and experiments in real networks. "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2018-02-12, 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, 2017-12-01, 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, 2017-12-01, 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. "Echo and Request-Tag", Christian Amsuess, John Mattsson, Goeran Selander, 2017-10-30, This document defines two optional extensions to the Constrained Application Protocol (CoAP): the Echo option and the Request-Tag option. Each of these options when integrity protected, such as with DTLS or OSCORE, protects against certain attacks on CoAP message exchanges. The Echo option enables a CoAP server to verify the freshness of a request by requiring the CoAP client to make another request and include a server-provided challenge. The Request-Tag option allows the CoAP server to match message fragments belonging to the same request message, fragmented using the CoAP Block-Wise Transfer mechanism. This document also specifies additional processing requirements on Block1 and Block2 options. "Secure group communication for CoAP", Marco Tiloca, Goeran Selander, Francesca Palombini, Jiye Park, 2018-02-12, This document describes a method for protecting group communication over the Constrained Application Protocol (CoAP). The proposed approach relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. All security requirements fulfilled by OSCORE are maintained for multicast OSCORE request messages and related OSCORE response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through private keys of sender devices and embedded in the protected CoAP messages. 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-01-02, 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. "Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH)", denis bider, 2017-10-12, This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections. "Extension Negotiation in Secure Shell (SSH)", denis bider, 2017-09-23, This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. "Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure", Simon Josefsson, Jim Schaad, 2017-11-14, This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", Russ Housley, 2017-08-22, This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). "Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)", Russ Housley, 2017-10-12, This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. "GSS-API Key Exchange with SHA2", Simo Sorce, Hubert Kario, 2018-02-22, 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. "Deprecate 3DES and RC4 in Kerberos", Benjamin Kaduk, Michiko Short, 2017-09-18, The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. "IANA Registration for new Cryptographic Algorithm Object Identifier Range", Jim Schaad, Rick Andrews, 2018-01-25, When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the range of identifiers that were assigned in that donated range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. "Deprecating RC4 in Secure Shell (SSH)", Luis Camara, 2018-01-26, This document deprecates RC4 in Secure Shell (SSH). Therefore, this document updates RFC 4253, and formally obsoletes and moves to Historic RFC 4345. "Ed25519 and Ed 448 public key algorithms for the Secure Shell (SSH) protocol", Ben Harris, Loganaden Velvindron, 2018-02-05, This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. DKIM Crypto Update (dcrup) -------------------------- "A new cryptographic signature method for DKIM", John Levine, 2018-01-22, This document adds a new signing algorithm to DKIM. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking Use Cases", Ethan Grossman, 2018-02-23, This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include professional audio, electrical utilities, building automation systems, wireless for industrial, cellular radio, industrial machine-to-machine, mining, private blockchain, and network slicing. For each case, this document will identify the application, identify representative solutions used today, and the improvements IETF DetNet solutions may enable. "Deterministic Networking Problem Statement", Norman Finn, Pascal Thubert, 2017-09-16, 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, 2017-10-30, Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes (e.g. bridges or routers) along the path of the flow; 2) providing explicit routes for DetNet flows that do not rapidly 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. The capabilities can be managed by configuration, or by manual or automatic network management. "Deterministic Networking (DetNet) Security Considerations", Tal Mizrahi, Ethan Grossman, Andrew Hacker, Subir Das, John Dowdell, Henrik Austad, Kevin Stanton, Norman Finn, 2017-10-30, 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 Data Plane Encapsulation", Jouni Korhonen, Loa Andersson, Yuanlong Jiang, Norman Finn, Balazs Varga, Janos Farkas, Carlos Bernardos, Tal Mizrahi, Lou Berger, 2018-01-29, This document specifies Deterministic Networking data plane encapsulation solutions. The described data plane solutions can be applied over either IP or MPLS Packet Switched Networks. "DetNet Flow Information Model", Janos Farkas, Balazs Varga, rodney.cummings@ni.com, Yuanlong Jiang, Yiyong Zha, 2018-01-10, 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. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael Richardson, Sheng Jiang, Ted Lemon, Timothy Winters, 2018-02-24, This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC3315, the original DHCPv6 specification, and incorporates prefix delegation (RFC3633), stateless DHCPv6 (RFC3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC7083), incorporates relay agent handling of unknown messages (RFC7283), and clarifies the interactions between modes of operation (RFC7550). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283, and RFC7550. "YANG Data Model for DHCPv6 Configuration", Yong Cui, Linhui Sun, Ian Farrer, Sladjana Zechlin, Zihao He, 2017-12-23, This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays, and clients. "Generalized UDP Source Port for DHCP Relay", Naiming Shen, Enke Chen, 2017-12-14, This document proposes an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications, and to include a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications. "DHCPv4 over DHCPv6 Source Address Option", Ian Farrer, Qi Sun, Yong Cui, Linhui Sun, 2017-12-12, DHCPv4 over DHCPv6 is a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator needs to know the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the clients IPv4 address and (in some deployments), the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process. This document updates "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" to allow the DHCPv6 option OPTION_S46_BR(90) to appear outside of DHCPv6 softwire container options. "DHCPv6 Options for LWM2M bootstrap information", Srinivasa Nalluri, 2017-08-28, This document defines Dynamic Host Configuration Protocol and Dynamic Host Configuration Protocol version 6 (DHCPv6) Options for LWM2M client bootstrap information, which are used to carry Uniform Resource Locater of LWM2M bootstrap server and certificate that validates the public key presented by server. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2018-01-08, 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, 2017-09-27, 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. "Diameter Credit-Control Application", Lyle Bertz, David Dolson, ylifshitz@sandvine.com, 2018-01-03, This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC4006, and it must be supported by all new Diameter Credit-Control Application implementations. Dispatch (dispatch) ------------------- "ECMAScript Media Types Updates", Bradley Farias, Matthew Miller, 2017-10-30, 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, Steven Jones, Seth Blank, Murray Kucherawy, 2018-01-22, 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, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Changes in the message that might break DKIM or DMARC can be identified through the ARC set of header fields. "Recommended Usage of the Authenticated Received Chain (ARC)", Steven Jones, Kurt Andersen, John Rae-Grant, J. Adams, 2018-01-22, The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. 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, 2018-01-22, 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, 2018-02-07, 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. Distributed Mobility Management (dmm) ------------------------------------- "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Vijay Devarapalli, 2017-11-13, Additional Identifier Type Numbers are defined for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). "On Demand Mobility Management", Alper Yegin, Danny Moses, Kisuk Kweon, Jinsung Lee, Jungshin Park, Seil Jeon, 2018-01-25, Applications differ with respect to whether they need IP 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. This document describes a solution for taking the application needs into account by selectively providing IP session continuity and IP address reachability on a per- socket basis. "Protocol for Forwarding Policy Configuration (FPC) in DMM", Satoru Matsushima, Lyle Bertz, Marco Liebsch, Sri Gundavelli, Danny Moses, Charles Perkins, 2017-10-30, This document describes a way, called Forwarding Policy Configuration (FPC) to manage the separation of data-plane and control-plane. FPC defines a flexible mobility management system using FPC agent and FPC client functions. An FPC agent provides an abstract interface to the data-plane. The FPC client configures data-plane nodes by using the functions and abstractions provided by the FPC agent for that data- plane nodes. The data-plane abstractions presented in this document is extensible, in order to support many different types of mobility management systems and data-plane functions. "DMM Deployment Models and Architectural Considerations", Sri Gundavelli, Seil Jeon, 2017-11-12, This document identifies the deployment models for Distributed Mobility Management architecture. "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Carlos Bernardos, 2018-03-02, 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 the 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 a new IP address configured from the new IP prefix which is anchored to the new network. The mobility functions and their operations and parameters are general for different configurations. "Segment Routing IPv6 for Mobile User-Plane", Satoru Matsushima, Clarence Filsfils, Miya Kohno, daniel.voyer@bell.ca, Charles Perkins, 2017-11-30, This document discusses the applicability of SRv6 (Segment Routing IPv6) to user-plane of mobile networks that SRv6 source routing capability with its programmability can fulfill the user-plane functions, such as access and anchor functions. It takes advantage of underlying layer awareness and flexibility to deploy user-plane functions that enables optimizing data-path for applications. Network slicing and an interworking way between SRv6 and existing mobile user-plane are also discussed in this document. Domain Name System Operations (dnsop) ------------------------------------- "DNS Multiple QTYPEs", Ray Bellis, 2018-01-02, This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2018-01-18, 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. ] "BULK DNS Resource Records", john.woodworth@centurylink.com, Dean Ballew, Shashwath Raghavan, David Lawrence, 2017-10-30, The BULK DNS resource record type defines a method of pattern-based creation of DNS resource records based on numeric substrings of query names. The intent of BULK is to simplify generic assignments in a memory-efficient way that can be easily shared between the primary and secondary nameservers for a zone. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2017-11-14, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the ip6.arpa zone for IPv6 address space assigned to many customers. "DNS Catalog Zones", Mukund Sivaraman, Stephen Morris, Ray Bellis, Witold Krecicki, 2018-03-01, This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. "DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara, 2017-11-27, The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. "A DNS Query including A Main Question with Accompanying Questions", Jiankang Yao, Paul Vixie, Ning Kong, XiaoDong Lee, 2017-09-17, This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit. "DNS Stateful Operations", Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Allison Mankin, Tom Pusateri, 2018-01-26, This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. "C-DNS: A DNS Packet Capture Format", John Dickinson, Jim Hague, Sara Dickinson, Terry Manderson, John Bond, 2018-02-22, 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. "Security Considerations for RFC5011 Publishers", Wesley Hardaker, Warren Kumari, 2018-02-01, This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document. "Address-specific DNS Name Redirection (ANAME)", Evan Hunt, Peter van Dijk, Anthony Eden, 2018-01-11, This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only redirects type A and AAAA queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to redirect queries for apex domain names in a standards compliant manner. "DNS Transport over TCP - Operational Requirements", John Kristoff, Duane Wessels, 2017-11-14, This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. It also describes some of the consequences of this behavior 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, 2017-10-16, This document defines an extensible method to return additional information about the cause of DNS errors. The primary use case is to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures. [ Open question: The document currently defines a registry for errors. It has also been suggested that the option also carry human readable (text) messages, to allow the server admin to provide additional debugging information (e.g: "example.com pointed their NS at us. No idea why...", "We don't provide recursive DNS to 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and DNS? We do DNS right..." (!). Please let us know if you think text is needed, or if a 16bit FCFS registry is expressive enough. ] [ Open question: This document discusses extended *errors*, but it has been suggested that this could be used to also annotate *non- error* messages. The authors do not think that this is a good idea, but could be persuaded otherwise. ] "Let 'localhost' be localhost.", Mike West, 2017-12-18, This document updates the treatment of the special-use domain name "localhost" as specified in RFC6761, Section 6.3, with the goal of ensuring that it can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. "Serving Stale Data to Improve DNS Resiliency", David Lawrence, Warren Kumari, 2017-10-30, This draft defines a method for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. "Secret Key Transaction Authentication for DNS (TSIG)", Francis Dupont, Stephen Morris, 2017-10-30, This protocol allows 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 recursive name server. No provision has been 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 such as sneaker-net until a secure automated mechanism for key distribution is available. This document includes revised original TSIG specifications (RFC2845) and the extension for HMAC-SHA (RFC4635). "A Sentinel for Detecting Trusted Keys in DNSSEC", Geoff Huston, Joao Damas, Warren Kumari, 2018-02-28, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determing which keys are in the trust store for the root key. There is an example / toy implementation of this at http://www.ksk- test.net . [ This document is being collaborated on in Github at: https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ] [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-"; older versions of this document used "_is-ta-", "_not-ta-". Also note that the format of the tag-index is now zero-filled decimal. Apolgies to those who have began implmenting.] Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "Discovery Proxy for Multicast DNS-Based Service Discovery", Stuart Cheshire, 2017-09-13, This document specifies a mechanism 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, 2017-10-30, The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is 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. "Privacy Extensions for DNS-SD", Christian Huitema, Daniel Kaiser, 2017-09-10, DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. "Device Pairing Using Short Authentication Strings", Christian Huitema, Daniel Kaiser, 2017-09-10, This document proposes a device pairing mechanism that establishes a relation between two devices by agreeing on a secret and manually verifying the secret's authenticity using an SAS (short authentication string). Pairing has to be performed only once per pair of devices, as for a re-discovery at any later point in time, the exchanged secret can be used for mutual authentication. The proposed pairing method is suited for each application area where human operated devices need to establish a relation that allows configurationless and privacy preserving re-discovery at any later point in time. Since privacy preserving applications are the main suitors, we especially care about privacy. "Device Pairing Design Issues", Daniel Kaiser, Christian Huitema, 2017-09-05, 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. DNS Over HTTPS (doh) -------------------- "DNS Queries over HTTPS", Paul Hoffman, Patrick McManus, 2018-02-02, DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. [[ There is a repository for this draft at https://github.com/dohwg/ draft-ietf-doh-dns-over-https [1] ]]. 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, 2017-11-12, The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol to facilitate interoperability between multivendor DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", Andrew Mortensen, Robert Moskowitz, Tirumaleswar Reddy, 2018-02-07, 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, Flemming Andreasen, Tirumaleswar Reddy, christopher_gray3@cable.comcast.com, Rich Compton, Nik Teague, 2017-10-25, This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Tirumaleswar Reddy, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague, 2018-01-23, 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 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"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", Tirumaleswar Reddy, Mohamed Boucadair, Kaname Nishizuka, Liang Xia, Prashanth Patil, Andrew Mortensen, Nik Teague, 2018-01-30, 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 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 this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model"; DNS PRIVate Exchange (dprive) ----------------------------- "Usage and (D)TLS Profiles for DNS-over-(D)TLS", Sara Dickinson, Daniel Gillmor, Tirumaleswar Reddy, 2017-09-11, This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only clear text DNS. This document also specifies new authentication mechanisms - it describes several ways a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS-over-(D)TLS. This document updates RFC 7858. "Padding Policy for EDNS(0)", Alexander Mayrhofer, 2018-02-07, RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify the actual padding length for specific applications. This memo lists the possible options ("Padding Policies"), discusses implications of each of these options, and provides a recommended (experimental) option. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane, 2017-11-27, 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, 2017-10-30, 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, 2018-01-28, 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 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. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens, 2017-10-30, 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, 2017-10-30, 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, 2017-10-31, 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. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "64bit body part and message sizes in IMAP4", Alexey Melnikov, Jayantheesh, 2017-10-28, This document defines an IMAPv4rev1 extension that extends the existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit. Both the base IMAP specification (RFC 3501) and several extensions are updated. "Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan Bosch, 2018-01-07, 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 an anonymous mailbox that has a particular special-use attribute assigned. "Internet Message Access Protocol (IMAP) - SAVEDATE Extension", Stephan Bosch, 2017-09-15, This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called 'save date' that, unlike the existing 'internal date' attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and it extends the SEARCH command to allow using that attribute in searching criteria. "Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension", Stephan Bosch, 2017-09-15, This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. "Sieve Extension: File Carbon Copy (Fcc)", Ken Murchison, Bron Gondwana, 2018-01-11, 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. "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST", Ken Murchison, Bron Gondwana, 2018-01-03, This document defines an extension to the to IMAP LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. General Area (gen) ------------------ "Update to Digital Signatures on Internet-Draft Documents", Russ Housley, 2018-01-18, RFC 5485 specifies the conventions for digital signatures on Internet-Draft documents. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. The RFC Editor recently published the first RFC that includes non- ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Draft document for non-ASCII characters in a text file. This document (once approved) updates RFC 5485. Global Routing Operations (grow) -------------------------------- "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Keyur Patel, Clarence Filsfils, 2017-12-14, This draft standardizes a new well-known BGP community GRACEFUL_SHUTDOWN to signal the graceful shutdown of paths. This draft also describes operational procedures which use this community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g. for planned maintenance. "Mitigating Negative Impact of Maintenance through BGP Session Culling", Will Hargrave, Matt Griswold, Job Snijders, Nick Hilliard, 2017-09-28, This document outlines an approach to mitigate negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions affected by the maintenance are forcefully torn down before the actual maintenance activities commence. "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente, 2018-02-23, 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, 2018-03-02, 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. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu, 2018-02-27, This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It 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, 2017-12-20, 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) ------------------------- "Outsourcing Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2017-10-27, Designation of services and devices of a home network is not user friendly, and mechanisms should enable a user to designate services and devices inside a home network using names. In order to enable internal communications while the home network experiments Internet connectivity shortage, the naming service should be hosted on a device inside the home network. On the other hand, home networks devices have not been designed to handle heavy loads. As a result, hosting the naming service on such home network device, visible on the Internet exposes this device to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. As result, home networks may prefer not serving the naming service for the Internet, but instead prefer outsourcing it to a third party. This document describes a mechanisms that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure. "DHCPv6 Options for Homenet Naming Architecture", Daniel Migault, Tomek Mrugalski, Chris Griffiths, Ralf Weber, Wouter Cloetens, 2017-10-27, The Homenet Naming Authority (HNA) is the designated device in charge of outsourcing the service to a third party, which requires setting up an architecture. Such settings may be inappropriate for most end users. This document defines DHCPv6 options so any agnostic HNA can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. "Homenet profile of the Babel routing protocol", Juliusz Chroboczek, 2018-02-22, This document defines the subset of the Babel routing protocol and its extensions that a Homenet router must implement, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel. "Special Use Domain 'home.arpa.'", Pierre Pfister, Ted Lemon, 2017-09-01, This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. "Simple Homenet Naming and Service Discovery Architecture", Ted Lemon, Daniel Migault, Stuart Cheshire, 2017-10-30, This document describes a simple name resolution and service discovery architecture for homenets, using the 'home.arpa' domain name hierarchy. This architecture covers local publication of names, as well as name resolution service for local and global names for devices connected to the homenet. This document does not cover discovery of homenet services by devices not connected to the homenet, nor DNSSEC, nor acquisition and configuration of a global name as an alternative to 'home.arpa'. These topics will be addressed in a separate document. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Anonymity, Human Rights and Internet Protocols", Stephane Bortzmeyer, Niels ten Oever, 2018-02-23, Anonymity is less discussed in the IETF than for instance security [RFC3552] or privacy [RFC6973]. This can be attributed to the fact anonymity is a hard technical problem or that anonymizing user data is not of specific market interest. It remains a fact that 'most internet users would like to be anonymous online at least occasionally' [Pew]. This document aims to break down the different meanings and implications of anonymity on a mediated computer network. Hypertext Transfer Protocol (httpbis) ------------------------------------- "HTTP Client Hints", Ilya Grigorik, 2018-01-26, An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. "The ORIGIN HTTP/2 Frame", Mark Nottingham, Erik Nygren, 2018-01-13, This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/origin-frame [3]. "Cache Digests for HTTP/2", Kazuho Oku, Mark Nottingham, 2018-02-28, This specification defines a HTTP/2 frame type to allow clients to inform the server of their cache's contents. Servers can then use this to inform their choices of what to push to clients. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/cache-digest . "Cookies: HTTP State Management Mechanism", Adam Barth, Mike West, 2017-08-07, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. "Structured Headers for HTTP", Mark Nottingham, Poul-Henning Kamp, 2018-02-01, This document describes a set of data types and parsing 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-02-26, This document defines a new HTTP header, named Expect-CT, that allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. When configured in enforcement mode, user agents (UAs) will remember that hosts expect SCTs and will refuse connections that do not conform to the UA's Certificate Transparency policy. When configured in report-only mode, UAs will report the lack of valid SCTs to a URI configured by the host, but will allow the connection. By turning on Expect-CT, web host operators can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs. "HTTP Random Access and Live Content", Craig Pratt, Barbara Stark, Darshak Thakore, 2017-11-14, 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. "Using Early Data in HTTP", Martin Thomson, Mark Nottingham, Willy Tarreau, 2017-11-23, This document explains the risks of using early data for HTTP and describes techniques for reducing them. In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation. "Bootstrapping WebSockets with HTTP/2", Patrick McManus, 2017-11-12, This document defines a mechanism for running the WebSocket Protocol [RFC6455] over a single stream of an HTTP/2 connection. "Secondary Certificate Authentication in HTTP/2", Mike Bishop, Nick Sullivan, Martin Thomson, 2017-12-05, TLS provides fundamental mutual authentication services for HTTP, supporting up to one server certificate and up to one client certificate associated to the session to prove client and server identities as necessary. This draft provides mechanisms for providing additional such certificates at the HTTP layer when these constraints are not sufficient. Many HTTP servers host content from several origins. HTTP/2 [RFC7540] permits clients to reuse an existing HTTP connection to a server provided that the secondary origin is also in the certificate provided during the TLS [I-D.ietf-tls-tls13] handshake. In many cases, servers will wish to maintain separate certificates for different origins but still desire the benefits of a shared HTTP connection. Similarly, servers may require clients to present authentication, but have different requirements based on the content the client is attempting to access. This document describes how TLS exported authenticators [I-D.ietf-tls-exported-authenticator] can be used to provide proof of ownership of additional certificates to the HTTP layer to support both scenarios. "On the use of HTTP as a Substrate", Mark Nottingham, 2018-02-28, HTTP is often used as a substrate for other application protocols. This document specifies best practices for these protocols' use of HTTP. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/bcp56bis [3]. "Bootstrapping WebSockets with HTTP/2", Patrick McManus, 2018-01-09, This document defines a mechanism for running the WebSocket Protocol [RFC6455] over a single stream of an HTTP/2 connection. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, Henk Birkholz, 2018-01-03, This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. "Requirements for Client-Facing Interface to Security Controller", Rakesh Kumar, Anil Lohiya, Dave Qi, Nabil Bitar, Senad Palislamovic, Liang Xia, 2018-01-16, This document captures requirements for Client-Facing interface to the Security Controller as defined by [I-D.ietf-i2nsf-framework]. The interface is expressed using objects and constructs understood by Security Admin as opposed to vendor or device specific expressions associated with individual product and feature. This document identifies a broad set of requirements needed to express Security Policies based on User-constructs which are well understood by the User Community. This gives ability to decouple policy definition from policy enforcement on a specific security functional element, be it a physical or virtual. "Information Model of NSFs Capabilities", Liang Xia, John Strassner, Cataldo Basile, Diego Lopez, 2017-09-30, This document 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 offer 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, 2017-11-13, 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, 2017-10-28, This document describes the use case of 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. This document describes a mechanism based on the SDN paradigm to support 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 IKE to establish security associations with a reduced intervention of the network administrator. NOTE: State data model will be developed as part of this work but it is still TBD. Interface to the Routing System (i2rs) -------------------------------------- "Routing Information Base Info Model", Nitin Bahadur, Sriganesh Kini, Jan Medved, 2018-02-13, Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model, and it was used by the IETF's I2RS WG to design the I2RS RIB data model. It is being published to record the higher level informational model decisions for RIBs so that other developers of RIBs may benefit from the design concepts. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Mach Chen, amit.dass@ericsson.com, Hariharan Ananthakrishnan, Sriganesh Kini, Nitin Bahadur, 2018-02-15, This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. "A Data Model for Network Topologies", Alexander Clemm, Jan Medved, Robert Varga, Nitin Bahadur, Hariharan Ananthakrishnan, Xufeng Liu, 2017-12-18, This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The data model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory data models. "A YANG Data Model for Layer 3 Topologies", Alexander Clemm, Jan Medved, Robert Varga, Xufeng Liu, Hariharan Ananthakrishnan, Nitin Bahadur, 2017-12-16, This document defines a YANG data model for layer 3 network topologies. "I2RS Environment Security Requirements", Daniel Migault, Joel Halpern, Susan Hares, 2017-09-27, This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. The security environment requirements are the good security practices to be used during implementation and deployment of the code related to the new interface to routing system (I2RS) so that I2RS implementations can be securely deployed and operated. Environmental security requirements do not specify the I2RS protocol seecurity requirements. This is done in another document (draft- ietf-i2rs-protocol-security-requirements). "A YANG Data Model for Fabric Topology in Data Center Networks", Zhuangyan, Danian Shi, Rong Gu, Hariharan Ananthakrishnan, 2018-02-11, This document defines a YANG data model for fabric topology in Data Center Network. Internet Architecture Board (iab) --------------------------------- "IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report", Natasha Rooney, Spencer Dawkins, 2018-02-19, The MarNEW workshop aimed to discuss solutions for bandwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members and various organisations involved in the telecommunications industry including original equipment manufacturers and mobile network operators. The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether the current issues experienced on the transport layer are also playing a role here. Content providers and CDNs gave an honest view of their experiences delivery content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible to implement or bad-for-privacy technologies back to regulators. A group of suggested solutions were devised which will be discussed in various IETF groups moving forward. Interactive Connectivity Establishment (ice) -------------------------------------------- "ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines", Paal-Erik Martinsen, Tirumaleswar Reddy, Prashanth Patil, 2016-11-13, This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", Ari Keranen, Christer Holmberg, Jonathan Rosenberg, 2018-02-27, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla, Justin Uberti, Peter Saint-Andre, 2018-02-25, This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. Information-Centric Networking (icnrg) -------------------------------------- "CCNx Semantics", Marc Mosko, Ignacio Solis, Christopher Wood, 2017-10-29, This document describes the core concepts of the CCNx architecture and presents a minimum 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. "CCNx Messages in TLV Format", Marc Mosko, Ignacio Solis, Christopher Wood, 2017-10-29, This document specifies version "1" of CCNx message 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 CCNx Semantics specification. "Research Directions for Using ICN in Disaster Scenarios", Jan Seedorf, Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2018-02-18, 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. "File-Like ICN Collection (FLIC)", Christian Tschudin, Christopher Wood, 2017-12-26, This document describes a bare bones "index table"-approach for organizing a set of ICN data objects into a large, File-Like ICN Collection (FLIC). At the core of this collection is a so called manifest which acts as the collection's root node. The manifest contains an index table with pointers, each pointer being a hash value pointing to either a final data block or another index table node. "Information-Centric Networking (ICN): CCN and NDN Terminology", Bastiaan Wissingh, Christopher Wood, Alex Afanasyev, Lixia Zhang, David Oran, Christian Tschudin, 2017-12-25, 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, Dipankar Raychadhuri, Emmanuel Baccelli, Jeff Burke, Guoqiang Wang, Bengt Ahlgren, Olov Schelen, 2018-02-16, 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 mostly information-centric nature of the IoT system. To address this mismatch the common set of protocols and network services offered by an information-centric network (ICN) architecture can be leveraged to realize ICN-IoT architectures. These ICN-IoT solutions leverages the salient features of ICN, and taking advantage of naming, security, mobility and efficient content and service delivery support. This draft summarizes general IoT demands, and covers the challenges and design to realize ICN-IoT frameworks based on ICN architecture. Beyond this, the goal of this draft is not to offer any specific ICN- IoT architectural proposals. "Native Deployment of ICN in LTE, 4G Mobile Networks", Prakash suthar, Milan Stolic, Anil Jangam, Dirk Trossen, Ravi Ravindran, 2018-02-04, 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, 2018-02-12, 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. Inter-Domain Routing (idr) -------------------------- "BGP Bestpath Selection Criteria Enhancement", Rajiv Asati, 2017-10-10, 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. "Dissemination of Flow Specification Rules for IPv6", Danny McPherson, Robert Raszuk, Burjiz Pithawala, akarch@cisco.com, Susan Hares, 2017-11-15, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Kevin Wang, 2017-10-14, 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, 2017-11-18, 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. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 2018-02-11, The current route target distribution specification as described in [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC 5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 2017-06-15, The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires. This document also defines a new BGP NOTIFICATION Cease Error subcode whose effect is to request a full session restart instead of a Graceful Restart. "Automatic Route Target Filtering for legacy PEs", Prodosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 2017-09-12, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra, 2017-10-23, 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. "Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute", Shitanshu Shah, Keyur Patel, Luis Tomotaki, Mohamed Boucadair, 2018-01-29, Network administrators typically enforce Quality of Service (QoS) policies according to Traffic Conditioning Agreement (TCA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of TCA, either thru TCA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, often manual, process and prone to errors. This document specifies an optional transitive attribute to signal TCA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks in situations where BGP is available as a routing protocol. "BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions", Les Ginsberg, Stefano Previdi, Qin Wu, Hannes Gredler, Saikat Ray, Jeff Tantsura, Clarence Filsfils, 2018-02-13, This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in IS-IS and OSPF protocols. "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, 2017-12-26, This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a router and advertise it into 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, 2017-10-30, 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. "Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang, Qin Wu, Jeff Tantsura, 2017-11-29, 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, Clarence Filsfils, Keyur Patel, Saikat Ray, Jie Dong, 2017-12-20, 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 allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Christoph Dietzel, 2018-02-14, 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. "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Brian Dickson, Keyur Patel, Andrei Robachevsky, 2017-09-06, RFC 7908 provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves intra-AS messaging from ingress router to egress router using a BGP Community or Attribute. This intra-AS messaging prevents the AS from causing route leaks. Another solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP fields are proposed to be carried in a new optional transitive attribute, called BGP RLP attribute. The RLP attribute helps with detection and mitigation of route leaks at ASes downstream from the leaking AS. "The BGP Tunnel Encapsulation Attribute", Eric Rosen, Keyur Patel, Gunter Van de Velde, 2018-02-28, 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-02-20, The Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging source routing. 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. This document defines an optional, transitive BGP attribute for announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) information. "Distribution of TRILL Link-State using BGP", Donald Eastlake, Hao Weiguo, Susan Hares, Sujay Gupta, Muhammad Durrani, Li Yizhou, 2017-10-03, This draft describes a TRILL link state and MAC address reachability information distribution mechanism using a BGP LS extension. External components such as an SDN Controller can use the information for topology visibility, troubleshooting, network automation, and the like. "Dissemination of NVO3 Flow Specification Rules", Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2017-11-16, This draft proposes a new subset of component types to support the NVO3 flow-spec application. "Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro, Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2018-01-28, [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2017-12-20, This document defines a new extended community known as flowspec redirect-to-indirection-id. This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to find the corresponding next-hop information within a indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the selected redirection path itself. "BGP Link-State extensions for Segment Routing", Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen, 2018-01-25, 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. "Advertising Node Admin Tags in BGP Link-State Advertisements", Pushpasis Sarkar, Hannes Gredler, Stephane Litkowski, 2018-01-17, This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. "Dissemination of Flow Specification Rules", Susan Hares, Christoph Loibl, Robert Raszuk, Danny McPherson, Martin Bacher, 2017-10-25, This document updates [RFC5575] which 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 updates [RFC5575] to correct unclear specifications in the flow filters and to provide rules for actions which interfere (e.g. redirection of traffic and flow filtering). 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-02-12, 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, 2018-01-01, 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 without any 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, 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 Maximum SID Depth using Border Gateway Protocol Link-State", Jeff Tantsura, Uma Chunduri, Gregory Mirsky, Siva Sivabalan, 2017-10-16, This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by a BGP-LS speaker. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels needs to know the MSD supported by the head-end at node and/or link granularity to push the SID stack of an appropriate depth. MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack. "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence Filsfils, Dhanendra Jain, Paul Mattes, Eric Rosen, Steven Lin, 2018-03-03, 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 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, 2017-12-18, This document defines the attributes to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node or link to a centralised controller (PCE/SDN). INtermediary-safe SIP session ID (insipid) ------------------------------------------ "Marking SIP Messages to be Logged", Peter Dawes, Chidambaram Arunachalam, 2017-12-19, SIP networks use signaling monitoring tools to diagnose user reported problems and for regression testing if network or user agent software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents, and therefore impractical to monitor SIP signaling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in normal user agent signaling. However, such marking can be carried end-to-end including the originating and terminating SIP user agents, even if a session originates and terminates in different networks. Internet Area Working Group (intarea) ------------------------------------- "IP Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley, 2018-01-19, This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459. "Privacy considerations for protocols relying on IP broadcast and multicast", Rolf Winter, Michael Faath, Fabian Weisshaar, 2018-01-19, A number of application-layer protocols make use of IP broadcasts or multicast messages for functions like local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcasts or multicast messages, a passive observer in the same broadcast/ multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use broadcast/multicast messages need to take special care when designing their protocols. "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2017-12-30, 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, 2018-01-15, This specification defines a set of the fundamental optional extensions for Generic UDP Encapsulation (GUE). "Discovering Provisioning Domain Names and Data", Pierre Pfister, Eric Vyncke, Tommy Pauly, David Schinazi, 2018-02-09, An increasing number of hosts access the Internet via multiple interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix configurations. This document describes a way for hosts to identify such means, called Provisioning Domains (PvDs), with Fully Qualified Domain Names (FQDN). 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 Performance Measurement (ippm) --------------------------------- "Model Based Metrics for Bulk Transport Capacity", Matt Mathis, Al Morton, 2017-09-15, We introduce a new class of Model Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance. Model Based Metrics rely on mathematical models to specify a Targeted Suite of IP Diagnostic tests, designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path. For Bulk Transport Capacity the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (bursts, etc) mimic TCP or other transport protocol carrying bulk data over a long path. However they are constructed to be independent of the details of the subpath under test, end systems or applications. Likewise the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems or application. "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip Eardley, Al Morton, Aamer Akhter, 2017-10-29, This document defines the format for the Performance Metrics registry and defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. "Initial Performance Metric Registry Entries", Al Morton, Marcelo Bagnulo, Philip Eardley, Kevin D'Souza, 2017-10-29, This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * Revised several Poisson streams to Periodic, sections 4 & 5. * Addition of ICMP (ping) metrics in section 9. * First implementation of Passive TCP RTT metrics in section 10. Still need: Add MBM metric entry. "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Al Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, 2018-02-13, This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). We define the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specify it using YANG. "IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework", Al Morton, Joachim Fabini, Nalini Elkins, mackermann@bcbsm.com, Vinayak Hegde, 2018-03-01, This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets in RFC 2330 to include IPv6 packets, deprecates the definition of minimum standard- formed packet, and augments distinguishing aspects of packets, referred to as Type-P for test packets in RFC 2330. This memo identifies that IPv4-IPv6 co-existence can challenge measurements within the scope of the IPPM Framework. Exemplary use cases include, but are not limited to IPv4-IPv6 translation, NAT, protocol encapsulation, IPv6 header compression, or use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN). "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, 2017-10-30, 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-03-01, This document describes a Simple Two-way Active Measurement Protocol which enables 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, 2018-03-01, 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. "OWAMP and TWAMP Well-Known Port Assignments", Al Morton, Gregory Mirsky, 2018-01-05, This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments. "Advanced Unidirectional Route Assessment (AURA)", Jose Alvarez-Hamelin, Al Morton, Joachim Fabini, Carlos Pignataro, 2018-02-16, 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. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)", Yoav Nir, 2017-10-27, This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. "Split DNS Configuration for IKEv2", Tommy Pauly, Paul Wouters, 2018-02-28, This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". "Postquantum Preshared Keys for IKEv2", Scott Fluhrer, David McGrew, Panos Kampanakis, Valery Smyslov, 2018-02-27, 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, 2017-11-27, 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 savec in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. 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, 2018-03-03, 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-based Vehicular Networking: Use Cases, Survey and Problem Statement", Jaehoon Jeong, 2017-11-13, This document discusses use cases, survey, and problem statement on IP-based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. First, this document surveys use cases using V2V and V2I networking. Second, this document deals with some critical aspects in vehicular networking, such as vehicular network architectures, standardization activities, IP address autoconfiguration, routing, mobility management, DNS naming service, service discovery, and security and privacy. For each aspect, this document discusses problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. Finally, this document articulates discussions including the summary and analysis of vehicular networking aspects and raises deployment issues. 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. "Advertising TE protocols in IS-IS", Shraddha Hegde, Chris Bowers, Paul Mattes, Mohan Nanduri, Spencer Giacalone, Imtiyaz Mohammad, 2017-09-15, This document defines a mechanism to indicate which traffic engineering protocols are enabled on a link in IS-IS. It does so by introducing a new traffic-engineering protocol sub-TLV for TLV-22. This document also describes mechanisms to address backward compatibility issues for implementations that have not yet been upgraded to software that understands this new sub-TLV. JSON Mail Access Protocol (jmap) -------------------------------- "JSON Meta Application Protocol", Neil Jenkins, 2017-11-28, This document specifies a protocol for synchronising JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. "JMAP for Mail", Neil Jenkins, 2017-11-28, This document specifies a data model for synchronising email data with a server using JMAP. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 2017-10-24, Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. "Channel Binding Signalling for the Generic Security Services Application Programming Interface", Robbie Harwood, Nico Williams, 2017-10-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. "Generic Security Service API Version 2: Java Bindings Update", Mayank Upadhyay, Seema Malkani, Wang Weijun, 2018-02-08, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). "SPAKE Pre-Authentication", Nathaniel McCallum, Simo Sorce, Robbie Harwood, Greg Hudson, 2018-02-10, This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without 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. L2VPN Service Model (l2sm) -------------------------- "A YANG Data Model for L2VPN Service Delivery", Bin Wen, Giuseppe Fioccola, Chongfeng Xie, Luay Jalil, 2018-02-22, This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The YANG model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing Liu, Giles Heron, 2017-10-30, This document defines a YANG data model for the configuration and management of Keyed IPv6 tunnels. The data model includes both configuration and state data. Due to the stateless nature of keyed IPv6 tunnels, a model for NETCONF notifications is not necessary. 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, 2017-04-14, 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. "Internationalized Email Addresses in X.509 certificates", Alexey Melnikov, Wei Chuang, 2018-02-12, This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. This document updates RFC 5280. "Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling", Jim Schaad, Blake Ramsdell, Sean Turner, 2017-04-07, 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. "Internationalization Updates to RFC 5280", Russ Housley, 2017-10-12, These updates to RFC 5280 provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for Internationalized Email Addresses in X.509 Certificates. "DNS Certification Authority Authorization (CAA) Resource Record", Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews, 2018-02-23, 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. 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. "Internet X.509 Public Key Infrastructure: Additional SHAKE Algorithms and Identifiers for RSA and ECDSA", Panos Kampanakis, Quynh Dang, 2018-02-16, This document describes the conventions for using the SHAKE family of hash functions in the Internet X.509 as one-way hash functions with the RSA and ECDSA signature algorithms; the conventions for the associated subject public keys are also described. Digital signatures are used to sign messages, certificates and CRLs (Certificate Revocation Lists). "Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)", Quynh Dang, Panos Kampanakis, 2018-02-16, This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS). Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-11-13, This document presents a base YANG Data model for the management of Operations Administration, and Maintenance (OAM) protocols that use Connectionless Communications. The data model is defined using the YANG, as specified in RFC7950 data modeling language. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. And second, it support both nested OAM workflows (i.e., performing OAM functions at different or same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at same levels through a unified interface). "Retrieval Methods YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-11-12, This document presents a retrieval method YANG Data model for connectionless OAM protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. And second, it support both nested OAM workflows (i.e., performing OAM functions at different or same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at same levels through a unified interface). "Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Qin Wu, Zitao Wang, 2018-02-25, This document presents a base YANG Data model for connection-oriented Operations, Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface). The YANG model in this document conforms to the Network Management Datastore Architecture. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2017-10-25, 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, 2018-01-04, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2018-02-27, When multicast sources and receivers are active at LISP sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data-plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. "LISP Distinguished Name Encoding", Dino Farinacci, 2017-09-18, This draft defines how to use the AFI=17 Distinguished Names in LISP. "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2017-10-23, This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. "The Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, David Meyer, Darrel Lewis, Albert Cabellos-Aparicio, 2018-02-13, 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. "Locator/ID Separation Protocol (LISP) Control-Plane", Vince Fuller, Dino Farinacci, Albert Cabellos-Aparicio, 2017-12-17, 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 infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. "LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal, Parantap Lahiri, 2017-10-30, 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, 2017-10-23, 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, 2017-11-15, 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, 2017-11-15, 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, as well as analyzing possible deployment options and models. "LISP Predictive RLOCs", Dino Farinacci, Padma Pillay-Esnault, 2017-11-30, This specification will describe 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, 2017-10-30, 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 LCAF", Alberto Rodriguez-Natal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino Farinacci, 2018-02-16, This document describes a new LCAF for LISP, the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. "LISP Generic Protocol Extension", Darrel Lewis, John Lemon, Puneet Agarwal, Larry Kreeger, Paul Quinn, Michael Smith, Navindra Yadav, Fabio Maino, 2018-01-24, This draft describes extending the Locator/ID Separation Protocol (LISP), via changes to the LISP header, to support multi-protocol encapsulation. IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "LPWAN Static Context Header Compression (SCHC) for CoAP", Ana Minaburo, Laurent Toutain, 2017-09-06, This draft defines the way SCHC header compression can be applied to CoAP headers. CoAP header structure differs from IPv6 and UDP protocols since the CoAP Header is flexible header with a variable number of options themself of a variable length. Another important difference is the asymmetry in the header information used for request and response messages. This draft takes into account the fact that a thing can play the role of a CoAP client, a CoAP client or both roles. "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP", Ana Minaburo, Laurent Toutain, Carles Gomez, 2018-02-28, This document defines the Static Context Header Compression (SCHC) framework, which provides header compression and fragmentation functionality. SCHC has been tailored for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in LPWAN devices and in the network. This document applies SCHC compression to IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over LPWAN technologies. Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or when it has not been possible to apply such compression, still exceed the layer two maximum payload size. The SCHC header compression mechanism is independent of the specific LPWAN technology over which it will be used. Note that this document defines generic functionality. This document purposefully offers flexibility with regard to parameter settings and mechanism choices, that are expected to be made in other, technology-specific, documents. "LPWAN Overview", Stephen Farrell, 2018-02-07, Low Power Wide Area Networks (LPWAN) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application layer data sizes and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. Link State Routing (lsr) ------------------------ "IS-IS Routing with Reverse Metric", Naiming Shen, Shane Amante, Mikael Abrahamsson, 2018-02-23, This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router. "IS-IS Extensions for Segment Routing", Stefano Previdi, Les Ginsberg, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, Jeff Tantsura, 2017-12-19, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. "OSPFv3 Extensions for Segment Routing", Peter Psenak, Clarence Filsfils, Stefano Previdi, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, 2018-01-26, 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. "YANG Data Model for IS-IS protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Zhaohui Zhang, Ladislav Lhotka, 2017-11-20, 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, 2018-03-03, This document defines a YANG data model that can be used to configure and manage OSPF. "Signaling Entropy Label Capability and Readable Label-stack Depth Using OSPF", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2018-01-03, Multiprotocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it has the capability of processing ELs, referred to as Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability of reading the maximum label stack depth, referred to as Readable Label-stack Depth (RLD), in the cases where stacked LSPs are used for whatever reasons. This document defines mechanisms to signal these two capabilities using OSPF. These mechanisms are useful when the label advertisement is also done via OSPF. In addition, this document introduces the Router Non-OSPF Functional Capabilities TLV for advertising OSPF router's actual non-OSPF functional capabilities. ELC is one of such non-OSPF functional capabilities. "Signaling Entropy Label Capability and Readable Label-stack Depth Using IS-IS", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2018-01-03, Multiprotocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it has the capability of processing ELs, referred to as Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability of reading the maximum label stack depth, referred to as Readable Label-stack Depth (RLD), in the cases where stacked LSPs are used for whatever reasons. This document defines mechanisms to signal these two capabilities using OSPF. These mechanisms are useful when the label advertisement is also done via IS-IS. "H-bit Support for OSPFv2", Keyur Patel, Padma Pillay-Esnault, Manish Bhardwaj, Serpil Bayraktar, 2018-01-28, OSPFv3 defines an option field for router-LSAs known as a R-bit in RFC5340. If the R-bit is clear, an OSPFv3 router can participate in OSPF topology distribution without acting as a forwarder to forward the transit traffic. In such cases, an OSPF router would only accept traffic intended for local delivery. This draft defines R-bit functionality for OSPFv2 defined in RFC2328. "Yang Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung, Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2017-12-28, This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. "YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2018-01-15, This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing ([I-D.ietf-isis-segment-routing-extensions]. "Signaling MSD (Maximum SID Depth) using OSPF", Jeff Tantsura, Uma Chunduri, Sam Aldrin, Peter Psenak, 2018-02-26, This document defines a way for an OSPF Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack is supportable in a given network. This document only defines one type of MSD (maximum label imposition) - but defines an encoding which can support other MSD types. Here the term OSPF means both OSPFv2 and OSPFv3. "Signaling MSD (Maximum SID Depth) using IS-IS", Jeff Tantsura, Uma Chunduri, Sam Aldrin, Les Ginsberg, 2018-01-10, This document defines a way for an IS-IS Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack is supportable in a given network. This document only defines one type of MSD (maximum label imposition) - but defines an encoding which can support other MSD types. "OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels", Anton Smirnov, Alvaro Retana, Michael Barnes, 2017-10-16, When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This 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. "OSPF LLS Extensions for Local Interface ID Advertisement", Peter Psenak, Ketan Talaulikar, Wim Henderickx, Padma Pillay-Esnault, 2017-11-20, This draft describes the extensions to OSPF link-local signaling to advertise Local Interface Identifier. "IS-IS TE Attributes per application", Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx, John Drake, 2017-11-14, 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. "OSPFv2 Link Traffic Engineering (TE) Attribute Reuse", Peter Psenak, Acee Lindem, Les Ginsberg, Wim Henderickx, Jeff Tantsura, Hannes Gredler, John Drake, 2018-01-30, Various link attributes have been defined in OSPFv2 in the context of the MPLS Traffic Engineering (TE) and GMPLS. Many of these link attributes can be used for purposes other than MPLS Traffic Engineering or GMPLS. This documents defines how to distribute such attributes in OSPFv2 for applications other than MPLS Traffic Engineering or GMPLS purposes. "IPv6 Source/Destination Routing using IS-IS", Fred Baker, David Lamparter, 2018-01-24, This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix. 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. "Energy-Efficient Features of Internet of Things Protocols", Carles Gomez, Matthias Kovatsch, Hui Tian, Zhen Cao, 2017-10-22, This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper layer protocols so that they can together achieve an energy efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained node networks. "CoAP Implementation Guidance", Matthias Kovatsch, Olaf Bergmann, Carsten Bormann, 2017-10-30, The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks such as sensor nodes in a low-power lossy network (LLN). Yet to implement this Internet protocol on Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of ROM) also lightweight implementation techniques are necessary. This document provides lessons learned from implementing CoAP for tiny, battery-operated networked embedded systems. In particular, it provides guidance on correct implementation of the CoAP specification RFC 7252, memory optimizations, and customized protocol parameters. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Back, 2018-02-26, This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches. "Neighbor Management Policy for 6LoWPAN", Rahul Jadhav, Rabi Sahoo, Simon Duquennoy, Joakim Eriksson, 2018-02-22, This document describes the problems associated with neighbor cache management in constrained multihop networks and a sample neighbor management policy to deal with it. "TCP Usage Guidance in the Internet of Things (IoT)", Carles Gomez, Jon Crowcroft, Michael Scharf, 2018-02-27, 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. Mobile Ad-hoc Networks (manet) ------------------------------ "DLEP Control Plane Based Pause Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2018-03-01, This document defines an extension to the DLEP protocol 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, 2018-02-20, 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-02-21, 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, 2018-03-01, This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. The extension is logically composed of two mechanisms. The first provides credit window control, the second identifies how flows are identified and mapped to a credit window. "Link Identifier Extension to DLEP", Rick Taylor, Stan Ratliff, 2018-01-30, There exists a class of modems that wish to support 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 individual DLEP destinations do exist, but are not directly reachable by MAC address. 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. MBONE Deployment (mboned) ------------------------- "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Kerry Meyer, Weesan Lee, 2017-12-20, This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a query and receives a reply. "Multicast in the Data Center Overview", Mike McBride, 2018-02-27, There has been much interest in issues surrounding massive amounts of hosts in the data center. These issues include the prevalent use of IP Multicast within the Data Center. Its important to understand how IP Multicast is being deployed in the Data Center to be able to understand the surrounding issues with doing so. This document provides a quick survey of uses of multicast in the data center and should serve as an aid to further discussion of issues related to large amounts of multicast in the data center. "Multicast Considerations over IEEE 802 Wireless Media", Charles Perkins, Mike McBride, Dorothy Stanley, Warren Kumari, Juan Zuniga, 2018-02-03, Well-known issues with multicast have prevented the deployment of multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other local-area wireless environments. IETF multicast experts have been meeting together to discuss these issues and provide IEEE updates. The mboned working group is chartered to receive regular reports on the current state of the deployment of multicast technology, create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies, and provide feedback to other relevant working groups. This document offers guidance on known limitations and problems with wireless multicast. Also described are various multicast enhancement features that have been specified at IETF and IEEE 802 for wireless media, as well as some operational chioces 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. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "Using XMPP for Security Information Exchange", Nancy Cam-Winget, Syam Appala, Scott Pope, Peter Saint-Andre, 2018-02-08, This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security-relevant information between network-connected devices. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF). "JSON binding of IODEF", Takeshi Takahashi, Roman Danyliw, Mio Suzuki, 2018-01-11, RFC 7970 [RFC7970] provides XML-based data representation on incident information, but the use of the IODEF data model is not limited to XML. JSON representation is sometimes preferred since it is easy to handle from certain programming environments. This draft represents the IODEF data model in JSON. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", Ali Begen, Paul Kyzivat, Colin Perkins, Mark Handley, 2018-02-18, 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-03-03, 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 allow assigning a zero port value to a "m=" section without meaning that the media described by the "m=" section is disabled or rejected. 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. "WebRTC MediaStream Identification in the Session Description Protocol", Harald Alvestrand, 2017-02-07, 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, Ari Keranen, Suhas Nandakumar, 2017-11-24, 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 Trickle ICE", Emil Ivov, Thomas Stach, Enrico Marocco, Christer Holmberg, 2018-02-24, 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) and defines a new SIP Info Package to support this usage. "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2017-12-20, 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, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, Roni Even, 2017-12-25, The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. 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 such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. "MSRP over Data Channels", Keith Drage, Maridi Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2017-09-10, 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 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-02-26, In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a 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. "Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile", Andrew Hutton, Roland Jesske, Alan Johnston, Gonzalo Salgueiro, Bernard Aboba, 2017-09-14, This document describes how the use of the Secure Real-time transport protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio Video Profile) defined in [RFC3551]. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/ AVPF) [RFC4585]. "Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP)", Martin Thomson, Eric Rescorla, 2018-01-30, Unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP) and its use with Web Real-Time Communications (WebRTC) identity assertions are described. Simple mitigation techniques are defined. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------------------------------------------ "Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom McGarry, 2017-07-03, The functions of the public switched telephone network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including telephone numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers which may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment, and proposes a framework for Internet-based services relying on TNs. 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, 2017-11-30, This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 8029. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC8029. "Entropy label for SPRING tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir, Jeff Tantsura, 2018-01-30, 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 when applied to the MPLS dataplane. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Gregory Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2017-12-05, Bidirectional Forwarding Detection (BFD) is expected to be able to monitor 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, 2018-01-03, 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. "MPLS Flow Identification Considerations", Stewart Bryant, Carlos Pignataro, Mach Chen, Zhenbin Li, Gregory Mirsky, 2018-03-01, This document discusses the aspects that need to be be considered when developing a solution for MPLS flow identification. The key application that needs this is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets. "Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula, Uwe Joorde, Arvind Venkateswaran, 2017-10-01, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing multicast LDP point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB module defined in this document is extension of LDP MIB defined in RFC3815 which supports only for LDP point-to-point LSPs. "A YANG Data Model for MPLS Base", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, 2018-02-15, This document contains a specification of the the MPLS base YANG model. The MPLS base YANG module serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE models) will augment the MPLS base YANG model. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, 2018-02-15, 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 LER(s) and 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, 2018-02-10, 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 RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling-rec) 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 semantics of Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling- rec). "YANG Data Model for MPLS mLDP", Kamran Raza, Sowmya Krishnaswamy, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura, 2017-11-12, 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. "YANG Data Model for MPLS LDP", Kamran Raza, Rajiv Asati, Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, 2017-11-12, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). This model also serves as the base model that is augmented to define Multipoint LDP (mLDP) model. "RFC6374 Synonymous Flow Labels", Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Gregory Mirsky, Giuseppe Fioccola, 2017-12-05, 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-01-29, draft-ietf-mpls-flow-ident 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, 2017-09-19, 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, 2017-12-18, 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. That is, it allows many more LSPs to be supported than there are forwarding plane labels available. This work 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. This document also introduces the ability to mix different types of label operations along the path of an LSP, thereby allowing the ingress router or an external controller to influence how to optimally place a LSP in the network. "MPLS Egress Protection Framework", Yimin Shen, Jeyananth Jeganathan, Bruno Decraene, Hannes Gredler, Carsten Michel, Huaimo Chen, Yuanlong Jiang, 2018-01-10, 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 egress node failure, and the egress router of the MPLS tunnel acts as the PLR for 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 to the protector. "SR-MPLS over IP", Xiaohu Xu, Stewart Bryant, Adrian Farrel, Ahmed Bashandy, Wim Henderickx, Zhenbin Li, 2018-02-28, MPLS Segment Routing (SR-MPLS in short) 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 could 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 preserving backward compatibility with SR-MPLS. 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/tunnelling such as MPLS-in- UDP [RFC7510]. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch, 2017-07-28, 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 [RFC6824] through clarifications and modifications primarily driven by deployment experience. Meeting Venue (mtgvenue) ------------------------ "IETF Plenary Meeting Venue Selection Process", Eliot Lear, 2018-02-01, The IASA has responsibility for arranging IETF plenary meeting Venue selection and operation. This document details the IETF's Meeting Venue Selection Process from the perspective of the community's goals, criteria and thought processes. It points to additional process documents on the IAOC Web Site that go into further detail and are subject to change with experience. "High level guidance for the meeting policy of the IETF", Suresh Krishnan, 2018-02-24, This document describes a proposed meeting location policy for the IETF and the various stakeholders for realizing such a policy. Network Configuration (netconf) ------------------------------- "Zero Touch Provisioning for Networking Devices", Kent Watsen, Mikael Abrahamsson, Ian Farrer, 2018-02-27, 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 [RFC6241] and/or RESTCONF [RFC8040] connections with deployment-specific network management systems. "YANG Datastore Subscription", Alexander Clemm, Eric Voit, Alberto Prieto, Ambika Tripathy, Einar Nilsen-Nygaard, Andy Bierman, Balazs Lengyel, 2018-02-23, 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 changes made upon YANG configuration and operational objects enables new capabilities based on the remote mirroring of configuration and operational state. "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu, 2017-10-30, 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, Gary Wu, 2017-10-30, 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. "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, Gary Wu, 2017-10-30, 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, Gary Wu, 2017-10-30, 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-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 "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 "2017-10-30" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log "NETCONF Support for Event Notifications", Alberto Prieto, Eric Voit, Alexander Clemm, Einar Nilsen-Nygaard, Ambika Tripathy, 2018-02-23, This document provides a NETCONF binding to subscribed notifications and to YANG push. RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. "RESTCONF and HTTP Transport for Event Notifications", Eric Voit, Ambika Tripathy, Einar Nilsen-Nygaard, Alexander Clemm, Alberto Prieto, Andy Bierman, 2018-01-31, This document defines RESTCONF, HTTP2, and HTTP1.1 bindings for the transport of subscription requests and corresponding push updates. Being subscribed may be either publisher defined event streams or nodes/subtrees of YANG Datastores. "YANG Data Model for a "Keystore" Mechanism", Kent Watsen, 2017-10-30, This document defines a YANG module called a "keystore", containing pinned certificates and pinned SSH host-keys. The module also defines a grouping for configuring public key pairs and a grouping for configuring certificates. The module also defines a notification that a system can use when one of its configured certificates is about to expire. "Network Configuration Access Control Module", Andy Bierman, Martin Bjorklund, 2017-12-11, The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. "Custom Subscription to Event Streams", Eric Voit, Alexander Clemm, Alberto Prieto, Einar Nilsen-Nygaard, Ambika Tripathy, 2018-02-23, This document defines capabilities and operations for the customized establishment of subscriptions upon a publisher's event streams. Also defined are delivery mechanisms for instances of the resulting notification messages. Effectively this allows a subscriber to request and receive a continuous, custom feed of publisher generated information. "YANG Library", Andy Bierman, Martin Bjorklund, Juergen Schoenwaelder, Kent Watsen, Robert Wilton, 2018-02-27, This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture by listing all datastores supported by a network management server and the schema that is used by each of these datastores. This document obsoletes RFC 7895. "RESTCONF Extensions to Support the Network Management Datastore Architecture", Martin Bjorklund, Juergen Schoenwaelder, Philip Shafer, Kent Watsen, Robert Wilton, 2018-03-01, This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of I-D.ietf-netconf-rfc7895bis by RESTCONF servers implementing the Network Management Datastore Architecture. REF Editor: please replace "I-D.ietf-netmod-revised-datastores" and "I-D.ietf-netconf-rfc7895bis" above with their final RFC assignments. "UDP based Publication Channel for Streaming Telemetry", Guangying Zheng, Tianran Zhou, Alexander Clemm, 2017-11-13, 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, 2018-02-20, 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. "NETCONF Extensions to Support the Network Management Datastore Architecture", Martin Bjorklund, Juergen Schoenwaelder, Philip Shafer, Kent Watsen, Robert Wilton, 2018-03-01, This document extends the NETCONF protocol defined in RFC 6241 in order to support the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document updates both RFC 6241 and RFC 7950. The update to RFC 6241 adds new operations and , and augments existing operations , , and . The update to RFC 7950 requires the usage of I-D.ietf-netconf-rfc7895bis by NETCONF servers implementing the Network Management Datastore Architecture. REF Editor: please replace "I-D.ietf-netmod-revised-datastores" and "I-D.ietf-netconf-rfc7895bis" above with their final RFC assignments. Network Modeling (netmod) ------------------------- "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2018-02-20, This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG data model modules. This document obsoletes RFC 6087. "A YANG Data Model for Syslog Configuration", Clyde Wildes, Kiran Koushik, 2018-03-01, 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. The YANG model in this document conforms to the Network Management Datastore Architecture defined in [draft-ietf-netmod-revised- datastores]. "Network Access Control List (ACL) YANG Data Model", Mahesh Jethanandani, Lisa Huang, Sonal Agarwal, Dana Blair, 2018-03-03, This document defines a data model for Access Control List (ACL). ACL is a ordered-by-user set of rules, used to configure the forwarding behavior in device. Each rule is used to find a match on a packet, and define actions that will be performed on the packet. "YANG Schema Mount", Martin Bjorklund, Ladislav Lhotka, 2017-10-21, This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. "A YANG Data Model for Hardware Management", Andy Bierman, Martin Bjorklund, Jie Dong, Dan Romascanu, 2018-01-22, This document defines a YANG data model for the management of hardware on a single server. "Network Management Datastore Architecture", Martin Bjorklund, Juergen Schoenwaelder, Philip Shafer, Kent Watsen, Robert Wilton, 2018-01-12, Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. "Sub-interface VLAN YANG Data Models", Robert Wilton, David Ball, tapsingh@cisco.com, Selvakumar Sivaraj, 2017-10-30, 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. Primarily the classification is based on VLAN identifiers in the 802.1Q VLAN tags, but the model also has support for matching on some other layer 2 frame header fields and is designed to be extensible to match on other arbitrary header fields. 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. "YANG Tree Diagrams", Martin Bjorklund, Lou Berger, 2018-02-08, This document captures the current syntax used in YANG module Tree Diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. "A YANG Data Model for IP Management", Martin Bjorklund, 2018-01-11, This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document obsoletes RFC 7277. "A YANG Data Model for Interface Management", Martin Bjorklund, 2018-01-11, This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document obsoletes RFC 7223. "A YANG Data Model for Routing Management (NMDA Version)", Ladislav Lhotka, Acee Lindem, Yingzhen Qu, 2018-01-26, This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. "YANG Data Extensions", Andy Bierman, Martin Bjorklund, Kent Watsen, 2018-02-19, This document describes YANG mechanisms for defining abstract data structures with YANG. It is intended to replace and extend the "yang-data" extension statement defined in RFC 8040. Internet Video Codec (netvc) ---------------------------- "