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 2017-10-20 13:05:25 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, 2017-06-04, 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, 2017-07-17, This specification proposes an update to IPv6 Neighbor Discovery, to enhance the operation of IPv6 over wireless links that exhibit lossy multicast support, and enable a large degree of scalability by splitting the broadcast domains. 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", Behcet Sarikaya, Pascal Thubert, Mohit Sethi, 2017-09-21, This document defines an extension to 6LoWPAN Neighbor Discovery RFC 6775. Nodes supporting this extension compute a cryptographic Owner Unique Interface ID and associate it with one or more of their Registered Addresses. 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-07-03, 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), 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. "An Update to 6LoWPAN ND", Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins, 2017-10-13, 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. IPv6 Maintenance (6man) ----------------------- "Support for adjustable maximum router lifetimes per-link", Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko, 2017-07-03, The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis. "IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils, Kamran Raza, 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, 2017-07-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. "IP Version 6 Addressing Architecture", Robert Hinden, Steve Deering, 2017-07-03, This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". "IPv6 Node Requirements", Tim Chown, John Loughney, Timothy Winters, 2017-07-03, 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 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-08-11, 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. "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2017-06-19, 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-09-22, 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 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. SFs are expected to be defined in future companion specifications. "Minimal Security Framework for 6TiSCH", Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson, 2017-06-15, This document describes the minimal mechanisms required to support secure enrollment of a pledge, a device being added to an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that the pledge has been provisioned with a credential that is relevant to the deployment - the "one-touch" scenario. The goal of this configuration is to set link-layer keys, and to establish a secure end-to-end session between each pledge and the join registrar who may use that to further configure the pledge. Additional security behaviors and mechanisms may be added on top of this minimal framework. "6tisch Zero-Touch Secure Join protocol", Michael Richardson, Benjamin Damm, 2017-09-08, 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. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Authentication and Authorization for Constrained Environments (ACE)", Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2017-10-19, 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, 2017-08-16, 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) Profile for Authentication and Authorization for Constrained Environments (ACE)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz, 2017-07-03, This specification defines a profile 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. 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, 2017-09-11, 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 the presenter being a 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, James Kasten, 2017-06-21, 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. "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. "Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites", Yaron Sheffer, Diego Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati, 2017-06-16, This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed certificates. This allows a domain name owner to delegate the use of certificates to another party, while retaining the capability to cancel this delegation at any time with no need to rely on certificate revocation mechanisms. [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-06-19, 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-06-19, This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use for email recipients that want to use S/MIME. "ACME Identifiers and Challenges for VoIP Service Providers", Mary Barnes, Chris Wendt, 2017-07-18, 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-07-03, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Multi-Cost ALTO", Sabine Randriamasy, Wendy Roome, Nico Schwan, 2017-04-27, The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO Filtered Cost Map and Endpoint Cost Map. In addition, it extends the constraints to further filter those maps by allowing a client to specify a logical combination of tests on several cost metrics. "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2017-07-03, 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 are 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-07-03, 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 costs enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to time-sensitive ALTO metrics. 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-07-03, 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. "Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery", Sebastian Kiesel, Martin Stiemerling, 2017-07-03, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the algorithm specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: http" or "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix. "ALTO Extension: Path Vector Cost Mode", Greg Bernstein, Shiwei Chen, Kai Gao, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, J. Zhang, 2017-07-03, 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. "Extensible Property Maps for the ALTO Protocol", Wendy Roome, Yang Yang, 2017-07-20, 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)", Michael Behringer, Toerless Eckert, Steinthor Bjarnason, 2017-10-13, 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, 2017-10-13, This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor'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, Peloso Pierre, Bing Liu, Jeferson Nobre, John Strassner, 2017-10-19, This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun, 2017-10-17, 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, 2017-10-18, 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 the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. "Voucher Profile for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, 2017-08-21, 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". The voucher artifact is a YANG-defined JSON document that has (by default) been signed using a PKCS#7 structure. The voucher artifact is normally generated by the pledge's manufacturer or delegate (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. Active Queue Management and Packet Scheduling (aqm) --------------------------------------------------- "Controlled Delay Active Queue Management", Kathleen Nichols, Van Jacobson, Andrew McGregor, Janardhan Iyengar, 2017-10-13, This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", Toke Hoeiland-Joergensen, Paul McKenney, dave.taht@gmail.com, Jim Gettys, Eric Dumazet, 2016-03-18, This memo presents the FQ-CoDel hybrid packet scheduler/Active Queue Management algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. Applications and Real-Time Area (art) ------------------------------------- "Representing DNS Messages in JSON", Paul Hoffman, 2017-05-08, 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. "Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9", Sean Leonard, 2017-03-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. "Web Linking", Mark Nottingham, 2017-08-11, This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST", Ken Murchison, Bron Gondwana, 2017-05-23, 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. "Scheme Specification for the pwid URI", Eld Zierau, 2017-06-09, 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 such web materials. The PWID URI ca 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. "Cancel-Locks in Netnews articles", Michael Bauerle, 2017-09-13, This document defines an extension to the Netnews Article Format that may be used to authenticate the cancelling and superseding of existing articles. If approved, this document updates RFC5537. "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. "LDAP Schema for supporting XMPP in White Pages", Steve Kille, 2017-10-12, The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of JID (Jabber IDs). Lightweight Directory Access Protocol (LDAP) enables provision of a white pages service with schema relating to users and support for internet protocols. This specification defines schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications. "Well-known URIs for the WebSocket Protocol", Carsten Bormann, 2017-05-11, RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs, specifically for the "http" and "https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes. 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. "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", Espen Berger, Suhas Nandakumar, Mo Zanaty, 2017-07-03, 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. "A General Mechanism for RTP Header Extensions", David Singer, HariKishan Desineni, Roni Even, 2017-08-02, This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. Audio/Video Transport Extensions (avtext) ----------------------------------------- "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli, 2016-08-03, Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. "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, 2017-07-03, 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, 2017-07-03, 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, 2017-08-22, Source-specific routing is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes the source-specific routing extension to the Standard Track's Babel routing protocol defined in [BABEL]. It is incompatible with the Experimental Track's Babel [RFC6126]. Source-specific routing is also known as Source Address Dependent Routing, SAD Routing, SADR, Destination/Source Routing or Source/ Destination Routing. BGP Enabled ServiceS (bess) --------------------------- "L2L3 VPN Multicast MIB", Zhaohui Zhang, Hiroshi Tsunoda, 2017-08-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-06-06, 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, 2017-08-28, 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, 2017-03-27, This document describes how Ethernet VPN (EVPN) can be used as an 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: VXLAN, NVGRE, and MPLS over GRE. "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, John Drake, 2017-07-18, 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 EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both. "IP Prefix Advertisement in EVPN", Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi, 2017-10-19, 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. "Propagation of IPv6 Neighbor Advertisement Flags in EVPN", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, 2017-07-03, 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. "E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, John Drake, Jim Uttaro, Sami Boutros, Jorge Rabadan, 2017-08-28, The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387 ("A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network"). This document discusses how those functional requirements can be met with a solution based on RFC7432, BGP MPLS Based Ethernet VPN (EVPN), with some extensions and how such a solution can offer a more efficient implementation of these functions than that of RFC7796, E-Tree Support in Virtual Private LAN Service (VPLS). This document makes use of the most significant bit of the "Tunnel Type" field (in PMSI Tunnel Attribute) governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2017-08-23, This draft defines protocol extensions required to synchronize flow label states among PEs 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, 2017-07-18, 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, 2017-08-16, 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, 2017-07-03, 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. "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", John Drake, Adrian Farrel, Eric Rosen, Keyur Patel, Luay Jalil, 2017-09-19, 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. "Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang, 2017-09-22, 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 RFC6625. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, Ing-Wher Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula, 2017-10-03, 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, Wim Henderickx, Autumn Liu, Wen Lin, 2017-10-11, 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-09-25, 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. "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com, 2017-06-21, RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks as the PE responsible for sending broadcast, multicast and unknown unicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing ES, or BUM and unicast in the case of single-active multi-homing. The DF is selected out of a candidate list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network, according to the 'service-carving' algorithm. While 'service-carving' provides an efficient and automated way of selecting the DF across different EVIs or ISIDs in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the current RFC7432 DF election procedures so that the above requirements can be met. "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. 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-07-03, This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R, 2017-02-08, The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, 2017-04-25, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. "BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks, 2017-04-25, This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Juniper Networks, Gregory Mirsky, 2017-06-30, This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, 2017-06-28, 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-05-11, 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-05-23, This document describes a security enhancements for the BFD packet's sequence number. Bit Indexed Explicit Replication (bier) --------------------------------------- "Multicast using Bit Index Explicit Replication", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Tony Przygienda, Sam Aldrin, 2017-09-13, This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree- building protocols results in a considerable simplification. "OSPF Extensions for BIER", Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Zhaohui Zhang, Sam Aldrin, 2017-10-03, 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 protocol extension required for BIER with MPLS encapsulation. "Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam Aldrin, Israel Meilik, 2017-10-18, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network, or with slight differences, in a non-MPLS network. "Multicast VPN Using BIER", Eric Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, Tony Przygienda, 2017-10-16, 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@thomsonreuters.com, Dom Robinson, Vishal Arya, Caitlin Bestler, 2017-07-17, 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, 2017-07-27, Specification of an ISIS extension to support BIER domains and sub- domains. "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, 2017-08-08, 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, 2017-07-18, This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Tony Przygienda, Andrew Dolganow, 2017-07-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, 2017-07-21, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2017-08-10, 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, 2017-07-31, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information. "BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols", Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda) Wang, Zheng Zhang, Markus Stenberg, 2017-06-30, This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain. "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan, 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). Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2017-10-02, 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. 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, 2017-10-02, This document defines the methodologies for benchmarking control plane performance of SDN controllers. Terminology related to benchmarking SDN controllers is described in the companion terminology document. 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, 2017-10-06, This document defines the methodologies for benchmarking performance of EVPN and PBB-EVPN.EVPN is defined in RFC 7432.It is being deployed in provider network.This document provides the benchmarking methodologies for EVPN/PBB-EVPN convergence,data plane,control plane learning of mac. 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. 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. Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- "Concise Binary Object Representation (CBOR)", Carsten Bormann, Paul Hoffman, 2017-10-14, 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, 2017-07-27, 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, Domenico Siracusa, Andrea Zanardi, Federico Pederzolli, Young Lee, Fatai Zhang, 2017-07-03, 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. "Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation", Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Andrea Zanardi, Domenico Siracusa, Federico Pederzolli, Young Lee, Fatai Zhang, 2017-07-03, This document defines an information model to support Impairment- Aware (IA) Routing and Wavelength Assignment (RWA) functionality. This information model extends the information model for impairment- free RWA process in WSON to facilitate computation of paths where optical impairment constraints need to considered. "OSPF-TE Link Availability Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2017-08-07, A network may contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links may change discretely in reaction to changing external environment. Availability is typically used for describing such links during network planning. This document defines a new type of the Generalized Switching Capability-specific information (SCSI) TLV to extend the Generalized Multi-Protocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note, this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology- specific documents will reference this document to describe specific uses. "Ethernet Traffic Parameters with Availability Information", Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2017-08-07, 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-09-05, To ensure an efficient data transport, meeting the requirements requested by today's IP-services the control and management of DWDM interfaces are a precondition for enhanced multilayer networking and for a further automation of network provisioning and operation. This document describes use cases, requirements and solutions for the control and management of optical interfaces 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 as well as control plane considerations in different management cases of single channel DWDM interfaces. The purpose is to identify the necessary information elements and processes to be used by control or management systems for further processing. "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, 2017-10-10, 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, Luis Contreras, Min Ye, Marko Vaupotic, Jeff Tantsura, Koji Kawada, Xi Li, Ippei Akiyoshi, Carlos Bernardos, Daniela Spreafico, 2017-10-19, To ensure an efficient data transport, meeting the requirements requested by today's transport services, the unification of control and management of microwave and millimeter wave radio link interfaces is a precondition for seamless multilayer networking and automated network wide 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. It focuses on the benefits of a standardized management model that is aligned with how other packet technology interfaces in a microwave/millimeter wave node are modeled, the need to support core parameters and at the same time allow for optional product/feature specific parameters supporting new, unique innovative features until they have become mature enough to be included in the standardized 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/millimeter wave node. Some part of the resulting model MAY be generic which COULD also be used by other technology. "Transport Northbound Interface Applicability Statement and Use Cases", Italo Busi, Daniel King, 2017-09-20, 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 for transport network control and management. It reviews proposed and existing IETF transport network data models, their applicability, and highlights gaps and requirements. "A YANG Data Model for Microwave Radio Link", Jonas Ahlberg, Min Ye, Xi Li, Koji Kawada, Carlos Bernardos, Daniela Spreafico, Marko Vaupotic, 2017-07-02, This document defines a YANG data model in order to control and manage the radio link interfaces, and the connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. "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-09-14, 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, 2017-07-17, This document describes the YANG data model for OTN Tunnels. "Transport Northbound Interface Applicability Statement and Use Cases", Italo Busi, Daniel King, 2017-10-10, 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 for transport network control and management. It reviews proposed and existing IETF transport network data models, their applicability, and highlights gaps and requirements. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, Phil Sorber, 2017-06-25, 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) ------------------------------------------------------------------------ "FF Video Codec 1", Michael Niedermayer, Dave Rice, Jerome Martinez, 2017-05-09, 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. "Extensible Binary Meta Language", Steve Lhomme, Dave Rice, Moritz Bunkus, 2017-07-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, 2017-07-03, 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, 2017-10-06, 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, 2017-07-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, 2017-10-16, This Internet-Draft describes SPAKE2, a secure, efficient password based key exchange protocol. "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Joost Rijneveld, Aziz Mohaisen, 2017-07-24, 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, 2017-07-26, 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, 2017-10-09, 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 external and internal 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. "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)", Paul Kyzivat, Lennard Xiao, Christian Groves, Robert Hansen, 2017-08-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) ------------------------------------- "Updates to the Opus Audio Codec", Jean-Marc Valin, Koen Vos, 2017-08-24, This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in the appendix of RFC 6716. The changes fixes real and potential security-related issues, as well minor quality-related issues. "Ambisonics in an Ogg Opus Container", Jan Skoglund, Michael Graczyk, 2017-05-02, 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, 2017-07-03, JavaScript Object Notation, JSON (RFC7159) 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 (RFC5988) 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 (RFC6690). 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, 2017-07-03, 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/ "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Carsten Bormann, Simon Lemay, Hannes Tschofenig, Klaus Hartke, Bill Silverajan, Brian Raymor, 2017-05-16, The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7252 fixing an erratum in the URI syntax, RFC 7641 for use with the new transports, and RFC 7959 to enable the use of larger messages over a reliable transport. "Media Types for Sensor Measurement Lists (SenML)", Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keranen, Carsten Bormann, 2017-07-03, 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 this media type 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, 2017-08-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, 2017-09-29, 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 encryption, integrity and replay protection, as well as a secure message binding. OSCORE is designed for constrained nodes and networks and can be used over any layer and across intermediaries, and also with HTTP. OSCORE may be used to protect group communications as is specified in a separate draft. "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2017-07-03, 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, Randy Turner, Ana Minaburo, Abhinav Somaraju, 2017-05-02, YANG Schema Item iDentifiers (SID) are globally unique 64-bit numeric identifiers used to identify all items used in YANG. 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-07-18, This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. "CoRE Resource Directory: DNS-SD mapping", Kerry Lynn, Peter Van der Stok, Michael Koster, Christian Amsuess, 2017-07-03, TBD CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448", Aris Adamantiadis, Simon Josefsson, Mark Baushke, 2017-05-11, 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, 2017-07-30, 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-09-12, 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. "Ed25519 public key algorithm for the Secure Shell (SSH) protocol", Ben Harris, Loganaden Velvindron, 2017-08-07, This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. "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. "More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)", Mark Baushke, 2017-09-15, This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 including an errata fix for checking the Peer's DH Public Key. "GSS-API Key Exchange with SHA2", Simo Sorce, Hubert Kario, 2017-06-15, This document specifies additions and amendments to SSH GSS-API Methods [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 Donated Symantec Website Security Object Identifier Range", Jim Schaad, Rick Andrews, 2017-09-12, When the Curdle Security Working Group was chartered, a range of object identifiers was donated by Symantec Website Security 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. "Increase SSH minimum recommended DH modulus size to 2048 bits", Loganaden Velvindron, Mark Baushke, 2017-09-22, The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minimum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors, and possibly any organization with enough computing resources. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. "Deprecating RC4 in all IETF Protocols", Luis Camara, 2017-08-08, RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx and it needs to be prohibited in all IETF protocols. This document obsoletes RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol" (note Arcfour and RC4 are synonymous). RFC 3501, RFC 4253, RFC 6649 and RFC 6733 are updated to note the deprecation of RC4 in all IETF protocols. DKIM Crypto Update (dcrup) -------------------------- "New cryptographic signature methods for DKIM", John Levine, 2017-09-13, DKIM was designed to allow new cryptographic algorithms to be added. This document adds a new signing algorithm and a new way to represent signature validation keys. "Cryptographic Algorithm and Key Usage Update to DKIM", D. Kitterman, 2017-08-21, The cryptographic algorithm and key size requirements included when DKIM was designed in the last decade are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimaly suitable for operation with currently specified algorithms. "Defining Elliptic Curve Cryptography Algorithms for use with DKIM", Scott Rose, 2017-06-21, DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking Use Cases", Ethan Grossman, Craig Gunther, Pascal Thubert, Patrick Wetterwald, Jean Raymond, Jouni Korhonen, Yu Kaneko, Subir Das, Yiyong Zha, Balazs Varga, Janos Farkas, Franz-Josef Goetz, Juergen Schmitt, Xavier Vilajosana, Toktam Mahmoodi, Spiros Spirou, Petra Vizarreta, Daniel Huang, Xuesong Geng, Diego Dujovne, Maik Seewald, 2017-09-18, 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-08-08, 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-02, A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7. 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, 2017-09-05, 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), and clarifies the interactions between modes of operation (RFC7550). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550. "Generalized UDP Source Port for DHCP Relay", Naiming Shen, Enke Chen, 2017-08-28, This document proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6. "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, 2017-09-15, 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, 2017-05-11, 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. Dispatch (dispatch) ------------------- "ECMAScript Media Types Updates", Bradley Farias, Matthew Miller, 2017-10-08, 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, Murray Kucherawy, 2017-09-07, The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination, 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, John Rae-Grant, J. Adams, Kurt Andersen, 2017-06-20, 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. Distributed Mobility Management (dmm) ------------------------------------- "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Vijay Devarapalli, 2017-07-21, 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, 2017-07-30, 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-09-13, 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. "MAG Multipath Binding Option", Pierrick Seite, Alper Yegin, Sri Gundavelli, 2017-09-25, This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile access gateway to register more than one proxy care-of-address with the local mobility anchor and to simultaneously establish multiple IP tunnels with the local mobility anchor. This capability allows the mobile access gateway to utilize all the available access networks for routing mobile node's IP traffic. "DMM Deployment Models and Architectural Considerations", Sri Gundavelli, Seil Jeon, 2017-08-29, This document identifies the deployment models for Distributed Mobility Management architecture. "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Alexandre Petrescu, Fred Templin, 2017-07-03, This document defines distributed mobility anchoring in terms of the different configurations, operations and parameters of mobility functions to provide different IP mobility support for the diverse mobility needs in 5G Wireless and beyond. A network may be configured with distributed mobility anchoring functions 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. For a flow requiring IP session continuity, the anchoring of the prior IP prefix may be moved to the new network. The mobility functions and their operations and parameters are general for different configurations. The mobility signaling may be between anchors and nodes in the network in a network-based mobility solution. It may also be between the anchors and the mobile node in a host-based solution. The mobile node may be a host, but may also be a router carrying a network requiring network mobility support. Domain Name System Operations (dnsop) ------------------------------------- "DNS Multiple QTYPEs", Ray Bellis, 2017-07-03, 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. "Returning extra answers in DNS responses.", Warren Kumari, Zhiwei Yan, Wesley Hardaker, David Lawrence, 2017-07-03, This document (re)introduces the ability to provide multiple answers in a DNS response. This is especially useful as, in many cases, the entity making the request has no a prori knowledge of what other questions it will need to ask. "BULK DNS Resource Records", john.woodworth@centurylink.com, Dean Ballew, Shashwath Raghavan, David Lawrence, 2017-07-03, 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. "DNS catalog zones", Mukund Sivaraman, Stephen Morris, Ray Bellis, Witold Krecicki, 2017-07-03, This document describes a method for automatic zone catalog provisioning and synchronization among DNS primary and secondary nameservers by storing and transferring the catalogs as regular DNS zones. "DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara, 2017-10-18, 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, 2017-09-13, This document defines a new DNS Stateful Operation OPCODE used to communicate operations within persistent stateful sessions, expressed using type-length-value (TLV) syntax, and defines an initial set of TLVs used to manage session timeouts and termination. This mechanism is intended to reduce the overhead of existing "per-packet" signaling mechanisms with "per-message" semantics as well as defining new stateful operations not defined in EDNS(0). "Let 'localhost' be localhost.", Mike West, 2017-08-31, This document updates RFC6761 with the goal of ensuring that "localhost" 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. "C-DNS: A DNS Packet Capture Format", John Dickinson, Jim Hague, Sara Dickinson, Terry Manderson, John Bond, 2017-07-03, 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. "Serving Stale Data to Improve DNS Resiliency", David Lawrence, Warren Kumari, 2017-06-27, 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. "Security Considerations for RFC5011 Publishers", Wesley Hardaker, Warren Kumari, 2017-10-18, This document extends the RFC5011 rollover strategy with timing advice that must be followed 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. It 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 trust anchor, and using RFC5011 to update that trust anchor, you probably don't need to read this document. 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. "Address-specific DNS Name Redirection (ANAME)", Evan Hunt, Peter van Dijk, Anthony Eden, 2017-05-27, 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-06-20, 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. ] 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-07-03, 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. 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-07-20, The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol that facilitates interoperability between multivendor solutions/services. This document presents use cases to evaluate 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, 2017-07-03, This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against 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-07-03, This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", Tirumaleswar Reddy, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague, 2017-10-12, 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. "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel", Tirumaleswar Reddy, Mohamed Boucadair, Kaname Nishizuka, Liang Xia, Prashanth Patil, Andrew Mortensen, Nik Teague, 2017-10-12, The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. 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, 2017-09-28, RFC 7830 specifies the EDNS0 'Padding' option, but does not specify the actual padding length for specific applications. This memo lists the possible options ("Padding Policies"), discusses the implications of each of these options, and provides a recommended (experimental) option. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane, 2017-08-08, 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-07-02, 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, 2017-05-21, 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 Protocl Version 7. Several new IANA registries are defined for TCPCLv4 which define some behaviors inherited from TCPCLv3 but with updated encodings and/or semantics. Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- "64bit body part and message sizes in IMAP4", Alexey Melnikov, Jayantheesh, 2017-09-18, This document defines an IMAPv4rev1 extension that extends the existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit. "Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan Bosch, 2017-09-15, 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. "Sieve Extension: File Carbon Copy (Fcc)", Ken Murchison, Bron Gondwana, 2017-09-21, The Sieve Email Filtering Language consists of action commands that can reply to the sender of an incoming message with a generated message. This document defines an extension to such commands to allow a copy of the generated reply message to be filed into a target mailbox. Open Issues o Should :fcc be allowed with reject/ereject? o Should there be a separate capability string for each action that uses :fcc (e.g. "vacation-fcc")? "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST", Ken Murchison, Bron Gondwana, 2017-09-21, 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) ------------------ "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee", Spencer Dawkins, 2017-09-02, This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee about the operations of the IETF Administrative Oversight Committee. This document updates RFC 7437. Global Routing Operations (grow) -------------------------------- "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Keyur Patel, Clarence Filsfils, 2017-10-12, 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, 2017-06-13, 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, 2017-06-21, 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, 2017-08-07, 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-04-25, 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. Home Networking (homenet) ------------------------- "Homenet profile of the Babel routing protocol", Juliusz Chroboczek, 2017-07-03, This document defines the subset of the Babel routing protocol [RFC6126] and its extensions that a Homenet router must implement, as well as the interactions between HNCP [RFC7788] 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, 2017-07-03, This document describes a simple name resolution and service discovery architecture for homenets. This architecture covers local publication of names, as well as name resolution for local and global names. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Research into Human Rights Protocol Considerations", Niels ten Oever, Corinne Cath, 2017-07-17, This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations [RFC6973]. If you want to apply this work to your own, you can directly go to Section 6. The rest of the document explains the background of the guidelines and how they were developed. This document is not an Internet Standards Track specification; it is published for informational purposes. This informational document has consensus for publication from the Internet Research Task Force (IRTF) Human Right Protocol Considerations Research Group. It is the first milestone in a longer term research effort and has been reviewed both by the research group and by individuals from outside the research group. Many of the topics discussed are still under discussion in the research group and will be subjects of continuing research. Hypertext Transfer Protocol (httpbis) ------------------------------------- "The ORIGIN HTTP/2 Frame", Mark Nottingham, Erik Nygren, 2017-08-23, 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/. 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/origin-frame. "Cache Digests for HTTP/2", Kazuho Oku, Mark Nottingham, 2017-05-29, 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. "HTTP Header Common Structure", Poul-Henning Kamp, 2017-04-25, An abstract data model for HTTP headers, "Common Structure", and a HTTP/1 serialization of it, generalized from current HTTP headers. 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/header-structure . "An HTTP Status Code for Indicating Hints", Kazuho Oku, 2017-07-11, This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. 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 https://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/early-hints . "Expect-CT Extension for HTTP", estark@google.com, 2017-08-14, 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-09-04, 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-10-19, 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. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, Henk Birkholz, 2017-07-03, This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. "Framework for Interface to Network Security Functions", Diego Lopez, Edward Lopez, Linda Dunbar, John Strassner, Rakesh Kumar, 2017-10-10, This document describes the framework for the Interface to Network Security Functions (I2NSF), and defines a reference model (including major functional components) for I2NSF. Network security functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated. "Software-Defined Networking (SDN)-based IPsec Flow Protection", Rafael Lopez, Gabriel Lopez-Millan, 2017-05-04, 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 SDN 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. "Requirements for Client-Facing Interface to Security Controller", Rakesh Kumar, Anil Lohiya, Dave Qi, Nabil Bitar, Senad Palislamovic, Liang Xia, 2017-07-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-10-02, 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. Interface to the Routing System (i2rs) -------------------------------------- "Routing Information Base Info Model", Nitin Bahadur, Sriganesh Kini, Jan Medved, 2017-06-16, 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 a information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh Kini, Nitin Bahadur, 2017-07-03, 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-09-19, 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-09-19, 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 Network", Zhuangyan, Danian Shi, Rong Gu, Hariharan Ananthakrishnan, 2017-08-23, 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, 2017-06-22, The MarNEW workshop aimed to discuss solutions for badnwidth 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, 2017-09-29, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. 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, 2017-09-11, 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-09-12, 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-09-12, 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, 2017-07-03, 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-06-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. 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. "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-08-15, 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. "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]. "Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute", Shitanshu Shah, Keyur Patel, Luis Tomotaki, Mohamed Boucadair, 2017-08-23, 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, 2017-08-18, 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, jefftant@gmail.com, 2017-07-01, 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. "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Jie Dong, Mach Chen, Robert Raszuk, 2017-07-03, The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2017-05-08, There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs. "Dissemination of Flow Specification Rules for L2 VPN", Hao Weiguo, liangqiandeng, Jim Uttaro, Stephane Litkowski, Shunwan Zhuang, 2017-07-03, This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. "Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang, Qin Wu, Jeff Tantsura, 2017-05-31, 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-06-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, Thomas King, 2017-07-03, 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, 2017-07-17, 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, 2017-10-17, 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 a 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 at the ingress node of the SR domain. This document defines a new 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. "Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro, Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2017-05-19, [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-08-30, 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 correct next-hop information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the actual redirection path selected. "BGP Link-State extensions for Segment Routing", Stefano Previdi, Peter Psenak, Clarence Filsfils, Hannes Gredler, Mach Chen, 2017-07-26, 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, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. "Advertising Node Admin Tags in BGP Link-State Advertisements", Pushpasis Sarkar, Hannes Gredler, Stephane Litkowski, 2017-07-25, 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-19, 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. "Signalling ERLD using BGP-LS", Gunter Van de Velde, Wim Henderickx, Matthew Bocci, Keyur Patel, 2017-04-24, This document defines the attributes to use for BGP-LS to expose a node or link ERLD "Entropy capable Readable Label Depth" to a centralised controller (PCE/SDN). "BGP Next-Hop dependent capabilities", Bruno Decraene, Kireeti Kompella, Wim Henderickx, 2017-06-30, 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, 2017-07-03, 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, Paul Mattes, Eric Rosen, Steven Lin, 2017-07-20, 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-07-27, This document defines the attributes to use for BGP-LS to expose a node or link ERLD "Entropy capable Readable Label Depth" to a centralised controller (PCE/SDN). INtermediary-safe SIP session ID (insipid) ------------------------------------------ "Marking SIP Messages to be Logged", Peter Dawes, Chidambaram Arunachalam, 2017-08-06, 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, 2017-06-08, 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 IP broadcast and multicast protocol designers", Rolf Winter, Michael Faath, Fabian Weisshaar, 2017-08-30, 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, broadcast/multicast protocol designers need to take special care when designing their protocols. "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2017-05-18, This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. "Discovering Provisioning Domain Names and Data", Pierre Pfister, David Schinazi, Tommy Pauly, Eric Vyncke, Basile Bruneau, 2017-07-27, An increasing number of hosts and networks are connected to the Internet through multiple interfaces, some of which may provide multiple ways to access the internet by the mean of multiple IPv6 prefix configurations. This document describes a way for hosts to retrieve additional information about their network access characteristics. The set of configuration items required to access the Internet is called a Provisioning Domain (PvD) and is identified by a Fully Qualified Domain Name (FQDN). This identifier, retrieved using a new Router Advertisement (RA) option, is associated with the set of information included within the RA and may later be used to retrieve additional information associated with the PvD by the mean of an HTTP request. "Extensions for Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Fred Templin, 2017-05-18, This specification defines a set of the fundamental optional extensions for Generic UDP Encapsulation (GUE). The extensions defined in this specification are the group identifier, security option, payload transform option, checksum option, fragmentation option, and the remote checksum offload option. "PROBE: A Utility For Probing Interfaces", Ron Bonica, Reji Thomas, J. Linkova, Chris Lenart, Mohamed Boucadair, 2017-09-26, This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. 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-06-30, 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-06-30, This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * Addition of Loss Ratio metric in various sections (multiple metrics per section). * All section 4, 5, 6, 7, and 8 parameters reference YANG types for alternate data formats. * implementation of standard naming format for parameters. * implementation of many IANA early-review comments. Still need: Add MBM metric entry. "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Al Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, 2017-10-19, 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. "Alternate Marking method for passive and hybrid performance monitoring", Giuseppe Fioccola, Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Mach Chen, Lianshu Zheng, Gregory Mirsky, Tal Mizrahi, 2017-10-03, This document describes a method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report is provided in order to explain an example and show the method applicability. This technique can be applied in various situations as detailed in this document and could be considered passive or hybrid depending on the application. "IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework", Al Morton, Joachim Fabini, Nalini Elkins, mackermann@bcbsm.com, Vinayak Hegde, 2017-10-11, 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-09-05, 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. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Implicit IV for Counter-based Ciphers in IPsec", Daniel Migault, Tobias Guggemos, Yoav Nir, 2017-06-21, IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. 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, saving 8 octets per packet. This document describes how to do this. "Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)", Yoav Nir, 2017-04-15, 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, 2017-07-29, This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should 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, 2017-10-19, 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. 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, 2017-10-16, 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. "Problem Statement for IP Wireless Access in Vehicular Environments", Jaehoon Jeong, Alexandre Petrescu, Tae Oh, Dapeng Liu, Charles Perkins, 2017-07-03, This document provides a problem statement for IP Wireless Access in Vehicular Environments (IPWAVE), that is, vehicular networks. This document addresses the extension of IPv6 as the network layer protocol in vehicular networks. It deals with networking issues in one-hop communication between a Road-Side Unit (RSU) and a vehicle, that is, "vehicle-to-infrastructure" (V2I) communication. It also deals with one-hop communication between two neighboring vehicles, that is, "vehicle-to-vehicle" (V2V) communication. Major issues about IPv6 in vehicular networks include neighbor discovery protocol, stateless address autoconfiguration, and DNS configuration for Internet connectivity. When a vehicle and an RSU have an internal network (respectively), the document discusses internetworking issues between two internal networks through either V2I or V2V communication. Those issues include prefix discovery, prefix exchange, service discovery, security, and privacy. "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems", Jaehoon Jeong, Sandra Cespedes, Nabil Benamar, Jerome Haerri, Michelle Wetterwald, 2017-07-03, This document surveys the general problem area 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. This document deals with some critical aspects in vehicular networking, such as IP address autoconfiguration, vehicular network architecture, routing, mobility management, and security. This document also surveys standard activities for vehicular networks. In addition, this documment surveys the use cases of IP-based vehicular networking for ITS. Finally, this document summarizes and analyzes the previous research activities that use IPv4 or IPv6 for vehicular networking. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Routing with Reverse Metric", Naiming Shen, Shane Amante, Mikael Abrahamsson, 2017-05-05, This document describes the mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to- point or multi-access LAN interface by signaling to an adjacent IS-IS neighbor with the metric towards itself during network maintenance or other operational events. "IPv6 Source/Destination Routing using IS-IS", Fred Baker, David Lamparter, 2017-07-18, This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, jefftant@gmail.com, 2017-06-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. "YANG Data Model for IS-IS protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Zhaohui Zhang, Ladislav Lhotka, 2017-07-25, This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT)", Zhenbin Li, Nan Wu, Quintin Zhao, Alia Atlas, Chris Bowers, Jeff Tantsura, 2017-06-30, This document describes extensions to IS-IS to support the distributed computation of Maximally Redundant Trees (MRT). Example uses of MRT include IP/LDP Fast-Reroute and global protection or live-live for multicast traffic. The extensions indicate what MRT profile(s) each router supports. Different MRT profiles can be defined to support different uses and to allow transition of capabilities. An extension is introduced to flood MRT-Ineligible links, due to administrative policy. This document also defines the Controlled Convergence sub-TLV, which is useful for MRT FRR as well as other applications. "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. "Advertising Tunnelling Capability in IS-IS", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2017-04-24, Some networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the ingress needs to select a type of tunnel which is supported by the egress. This document defines how to advertise egress tunnel capabilities in IS-IS Router Capability TLV. "YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2017-07-25, 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 IS-IS", Jeff Tantsura, Uma Chunduri, Sam Aldrin, Les Ginsberg, 2017-06-04, This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by an IS-IS Router. 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. "IS-IS TE Attributes per application", Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx, John Drake, 2017-10-12, 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. JSON Mail Access Protocol (jmap) -------------------------------- "JSON Meta Application Protocol", Neil Jenkins, 2017-07-16, 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-07-16, This document specifies a data model for synchronising email data with a server using JMAP. Javascript Object Notation Update (jsonbis) ------------------------------------------- "The JavaScript Object Notation (JSON) Data Interchange Format", Tim Bray, 2017-07-19, JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 2017-04-25, 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, 2017-08-04, 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, 2017-09-15, 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, 2017-09-18, 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 data 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. 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, 2017-09-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. "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. Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- "Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-09-20, This document presents a base YANG Data model for connectionless Operations Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. The base model presented here can be extended to include technology specific details. This is leading to uniformity between OAM protocols and support both nested OAM workflows (i.e., performing OAM functions at different or same levels through a unified interface) and interacting OAM workflows ( i.e., performing OAM functions at same levels through a unified interface). "Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-10-11, This document presents a retrieval method YANG Data model for connectionless OAM protocols. It provides technology-independent RPC operations for connectionless OAM protocols. The retrieval methods model presented here can be extended to include technology specific details. This is leading to uniformity between OAM protocols and support both nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface) and interacting 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, 2017-06-09, This document presents a base YANG Data model for connection oriented 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) Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2017-09-20, 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, 2017-07-03, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2017-08-01, 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-04-28, 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, 2017-08-29, 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. The map-cache is populated by the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. 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-10-05, 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-04-28, 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-04-28, 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-05-11, 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-05-11, 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-06-07, 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-08-17, 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, 2017-08-17, This document describes a new LCAF for LISP, the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- "Using RESTCONF with LMAP Measurement Agents", Juergen Schoenwaelder, Vaibhav Bajpai, 2017-06-02, This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). 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, 2017-09-12, This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields and must be used for these kind of networks. A common context stored in a LPWAN device and in the network is used. This context keeps information that will not be transmitted in the constrained network. Static context means that information stored in the context, which describes field values, does not change during packet transmission. This avoids complex resynchronization mechanisms, which are incompatible with LPWAN characteristics. In most cases, IPv6/UDP headers are reduced to a small identifier called Rule ID. But sometimes, a packet will not be compressed enough by SCHC to fit in one L2 PDU, and the SCHC fragmentation protocol will be used. This document describes the SCHC compression/decompression framework and applies it to IPv6/UDP headers. Similar solutions for other protocols such as CoAP will be described in separate documents. Moreover, this document specifies a fragmentation and reassembly mechanism that is used in two situations: for SCHC-compressed packets that still exceed the L2 PDU size; and for the case where the SCHC compression cannot be performed. "LPWAN Overview", Stephen Farrell, 2017-10-03, 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. 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-03-05, 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. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Back, 2017-08-09, 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 small devices and presents some preliminary experiences with those libraries for message signing on small devices. Lastly, the memo discusses trade-offs involving different types of security approaches. "Neighbor Management Policy for 6LoWPAN", JADHAV RAHUL, Rabi Sahoo, Simon Duquennoy, Joakim Eriksson, 2017-08-28, 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, 2017-10-15, 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) ------------------------------ "Rules for Designing Protocols Using the RFC 5444 Generalized Packet/ Message Format", Thomas Clausen, Christopher Dearlove, Ulrich Herberg, Henning Rogge, 2017-07-18, RFC 5444 specifies a generalized MANET packet/message format and describes an intended use for multiplexed MANET routing protocol messages that is mandated to use on the port or protocol specified by RFC 5498. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use optional generic parsers. "DLEP Control Plane Based Pause Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2017-07-03, This document defines an extension to the DLEP protocol that enables a simple control plane based flow control mechanism. MBONE Deployment (mboned) ------------------------- "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Kerry Meyer, Weesan Lee, 2017-10-14, 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. "Use of Multicast Across Inter-Domain Peering Points", Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, Ram Krishnan, 2017-09-28, This document examines the use of Source Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objective is to describe the setup process for multicast-based delivery across administrative domains for these scenarios and document supporting functionality to enable this process. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "Incident Object Description Exchange Format Usage Guidance", Panos Kampanakis, Mio Suzuki, 2017-09-07, The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) . Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world. "Resource-Oriented Lightweight Information Exchange", John Field, Stephen Banghart, David Waltermire, 2017-09-29, This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on- demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations. "Using XMPP Protocol and its Extensions for Use with IODEF", Nancy Cam-Winget, Syam Appala, Scott Pope, 2017-07-03, This document describes how the Extensible Messaging and Presence Protocol (XMPP) [RFC7590] can be used as the framework as transport protocol for collecting and distributing any security telemetry information between any network connected device. As an example, this document describes how XMPP can be used to transport the Incident Object Description Exchange Format (IODEF) information. "JSON binding of IODEF", Takeshi Takahashi, Mio Suzuki, 2017-09-27, 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. Note that this 00 version draft is prepared for the purpose of encouraging discussion on the need for JSON representation. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", Mark Handley, Colin Perkins, Ali Begen, 2017-10-07, 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, 2017-08-31, 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 address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. "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-10-02, 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, 2016-12-19, 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, 2017-10-16, 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 Info Package as specified in [RFC6086]. "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2017-07-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, 2017-09-10, 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-07, 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", Peter Thatcher, Mo Zanaty, Suhas Nandakumar, Bo Burman, Adam Roach, Byron Campen, 2017-07-19, 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, 2017-08-01, 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) ------------------------------------ "Requirements for hitless MPLS path segment monitoring", Alessandro D'Alessandro, Loa Andersson, Satoshi Ueno, Kaoru Arai, Yoshinori Koike, 2017-09-01, One of the most important OAM capabilities for transport network operation is fault localisation. An in-service, on-demand segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between end points. However, the current segment monitoring approach defined for MPLS (including the transport profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS- Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support a Hitless Path Segment Monitoring (HPSM). "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-05-19, 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. "LDP Extensions to Support Maximally Redundant Trees", Alia Atlas, Kishore Tiruveedhula, Chris Bowers, Jeff Tantsura, IJsbrand Wijnands, 2017-08-17, This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs (Label Switching Routers) and LERs (Label Edge Routers) advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the MPLS MT-ID space. "Entropy label for SPRING tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir, jefftant@gmail.com, 2017-10-17, 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-06-13, 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. "RFC6374 Synonymous Flow Labels", Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Gregory Mirsky, Giuseppe Fioccola, 2017-04-26, 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. "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2017-07-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, 2017-07-27, This memo discusses the aspects that must be considered when developing a solution for MPLS flow identification. The key application that needs this is in-band performance monitoring of 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. "LDP Specification", Xia Chen, Loa Andersson, Nicolai Leymann, Ina Minei, Kamran Raza, 2017-04-26, The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. "Label Switched Path (LSP) Ping/Traceroute for Segment Routing IGP Prefix and Adjacency SIDs with MPLS Data-plane", Nagendra Kumar, Carlos Pignataro, George Swallow, Nobo Akiya, Sriganesh Kini, Mach Chen, 2017-10-17, A Segment Routing architecture leverages source routing and tunneling paradigms and can be directly applied to use of a Multi Protocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with a Segment Routing header. The segment assignment and forwarding semantic nature of Segment Routing raises additional consideration for connectivity verification and fault isolation for an LSP within a Segment Routing architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP Prefix and Adjacency SIDs with an MPLS data plane. "A YANG Data Model for MPLS Base", Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Tarek Saad, Igor Bryskin, Xia Chen, Raqib Jones, Bin Wen, 2017-07-02, 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, Himanshu Shah, Igor Bryskin, Xia Chen, Raqib Jones, Bin Wen, 2017-07-02, 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, 2017-08-11, 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. "YANG Data Model for MPLS mLDP", Kamran Raza, Sowmya Krishnaswamy, Xufeng Liu, Santosh Esale, Xia Chen, Jeff Tantsura, 2017-09-14, 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-09-14, 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-06-12, This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374. "Synonymous Flow Label Framework", Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Gregory Mirsky, 2017-08-01, 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. 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, 2017-09-12, 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 its 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, 2017-07-03, This document describes a proposed meeting policy for the IETF and the various stakeholders for realizing such a policy. Network Configuration (netconf) ------------------------------- "Zero Touch Provisioning for NETCONF or RESTCONF based Management", Kent Watsen, Mikael Abrahamsson, Ian Farrer, 2017-10-19, This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its preconfigured initial state (e.g., factory default settings), and its deployment specific network management system (NMS). "Subscribing to YANG datastore push updates", Alexander Clemm, Eric Voit, Alberto Prieto, Ambika Tripathy, Einar Nilsen-Nygaard, Andy Bierman, Balazs Lengyel, 2017-10-03, Providing rapid visibility into changes made on YANG configuration and operational objects enables new capabilities such as remote mirroring of configuration and operational state. Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu, 2017-10-19, 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, Juergen Schoenwaelder, 2017-07-03, 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. "SSH Client and Server Models", Kent Watsen, Gary Wu, 2017-06-13, 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, Juergen Schoenwaelder, 2017-07-03, 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-07-03" --> 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, Alexander Clemm, Eric Voit, Einar Nilsen-Nygaard, Ambika Tripathy, 2017-10-03, This document defines how to transport network subscriptions and event messages on top of the Network Configuration protocol (NETCONF). This includes the full set of RPCs, subscription state changes, and subscribed content needing asynchronous delivery. "Restconf and HTTP Transport for Event Notifications", Eric Voit, Ambika Tripathy, Einar Nilsen-Nygaard, Alexander Clemm, Alberto Prieto, Andy Bierman, 2017-08-04, 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-17, This document defines a YANG module for a system-level mechanism, called a "keystore", containing security-sensitive data including private keys, pinned certificates, and pinned SSH host-keys. "Network Configuration Access Control Module", Andy Bierman, Martin Bjorklund, 2017-10-10, 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 Notifications", Eric Voit, Alexander Clemm, Alberto Prieto, Einar Nilsen-Nygaard, Ambika Tripathy, 2017-10-03, 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 events. Effectively this allows a subscriber to request and receive a continuous, custom influx of publisher generated information. "YANG Library", Andy Bierman, Martin Bjorklund, Kent Watsen, 2017-08-31, This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. "RESTCONF Update to Support the NMDA", Martin Bjorklund, Juergen Schoenwaelder, Philip Shafer, Kent Watsen, Robert Wilton, 2017-08-24, This document updates RESTCONF [RFC8040] in order to support the Network Management Datastore Architecture (NMDA) defined in [I-D.ietf-netmod-revised-datastores]. "UDP based Publication Channel for Streaming Telemetry", Guangying Zheng, Tianran Zhou, Alexander Clemm, 2017-09-25, 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, Andy Bierman, Alexander Clemm, Tim Jenkins, 2017-10-03, 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 Model for NMDA", Martin Bjorklund, Juergen Schoenwaelder, Philip Shafer, Kent Watsen, Robert Wilton, 2017-10-11, The "Network Management Datastore Architecture" (NMDA) improves on NETCONF by adding new features to give more accurate handling of configuration and operational data. These include ability to inspect the current operational values of configuration data, allowing clients to use identical paths for retrieving the configured values and the operational values. These new features require additional operations in network management applications such as NETCONF. This draft details those new operations. Network Modeling (netmod) ------------------------- "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2017-09-08, 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, 2017-09-08, 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. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "xxxx" --> the assigned RFC value for draft-ietf-netconf-keystore o "yyyy" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "zzzz" --> the assigned RFC value for this draft "Network Access Control List (ACL) YANG Data Model", Mahesh Jethanandani, Lisa Huang, Sonal Agarwal, Dana Blair, 2017-10-03, This document describes a data model of Access Control List (ACL) basic building blocks. 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. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft both in this draft and in the YANG models under the revision statement. o Revision date in model needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . "Terminology and Requirements for Enhanced Handling of Operational State", Kent Watsen, Thomas Nadeau, 2016-01-22, This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. "YANG Schema Mount", Martin Bjorklund, Ladislav Lhotka, 2017-09-27, This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. "Common Interface Extension YANG Data Models", Robert Wilton, David Ball, tsingh@juniper.net, Selvakumar Sivaraj, 2017-07-03, This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. "A YANG Data Model for Hardware Management", Andy Bierman, Martin Bjorklund, Jie Dong, Dan Romascanu, 2017-10-16, 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, 2017-10-20, 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. "Sub-interface VLAN YANG Data Models", Robert Wilton, David Ball, tapsingh@cisco.com, Selvakumar Sivaraj, 2017-07-03, 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, 2017-06-30, This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the 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, 2017-08-21, This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277. "A YANG Data Model for IP Management", Martin Bjorklund, 2017-10-16, This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277. "A YANG Data Model for Interface Management", Martin Bjorklund, 2017-10-16, 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). This document obsoletes RFC 7223. Internet Video Codec (netvc) ---------------------------- "